Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/go: go install documentation is lacking; effect of $GOBIN underdocumented #31576

Closed
griesemer opened this issue Apr 19, 2019 · 3 comments
Closed
Labels
Documentation FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done. release-blocker
Milestone

Comments

@griesemer
Copy link
Contributor

It's been a while since I had to fiddle with my dev setup but I recently created a new separate go repo in my home directory and it took me a while to untangle where which binaries got installed. Specifically when it comes to uses of $GOBIN for which the documentation is a bit vague. It says that if $GOBIN is set, the go command installs all commands there. Well, that's not what I am observing.

I have no Go specific environment variables set but for GOPATH which is set to $HOME. So no GOBIN, or GOROOT per the usual recommendation.

In a brand-new local repo of the Go distribution, after running make.bash, the two tools go and gofmt are built and installed in $GOROOT/bin where $GOROOT is the repo directory (per documentation). It doesn't matter if $GOBIN is set or not.

go install of a new "command", that is a main package under $GOROOT/src/cmd, appears to be installed in $GOTOOLDIR no matter if $GOBIN is set or not. $GOTOOLDIR is $GOROOT/pkg/tool/GOOS_$GOARCH.

Only for binaries (main packages) outside $GOROOTsrc/cmd does $GOBIN apply: Those end up in $GOBIN if it set, or in GOROOT/bin if $GOBIN is not set.

(This is all based in empirical evidence, I haven't studied the code. Happy to be corrected if I got this wrong.)

The documentation should be more clear. Right now we have lists of environment variables and respective documentation which is referred to from various places but it's not consistent.

More generally, it would be useful to document the recommended basic dev setup for people who want to work on the std lib. Specifically, where what is installed. Note that go help install doesn't say anything about what "install" actually means or where things go. It refers to go help build and go help packages which only makes things complicated.

cc: @bcmills

@griesemer griesemer added this to the Go1.13 milestone Apr 19, 2019
@griesemer griesemer changed the title cmd/go: $GOBIN effect on go install unclear cmd/go: go install documentation is lacking; effect of $GOBIN underdocumented Apr 19, 2019
@gertcuykens
Copy link
Contributor

gertcuykens commented Apr 21, 2019

Hmm is it possible to do it the other way around? So let's try to keep the consistency and do what the documentation suggest instead of modifying the doc. So $GOBIN is always king: go modules or go path or go root stuff doesn't matter, always put it in $GOBIN. I understand it will break a lot of things but nothing I think where make files and build scripts can't adapt to by modifying $GOBIN on the fly?

@griesemer
Copy link
Contributor Author

@gertcuykens I doubt that we can change the existing behavior w/o breaking a large number of people's setups. Updating the documentation is probably the way to go. But leaving this to the people responsible for the current behavior.

cc: @rsc

@ianlancetaylor ianlancetaylor added NeedsFix The path to resolution is known, but the work has not been done. release-blocker labels May 22, 2019
@jayconrod jayconrod self-assigned this Jun 13, 2019
@gopherbot
Copy link

Change https://golang.org/cl/182341 mentions this issue: cmd/go: document GOBIN and 'go install' locations

@golang golang locked and limited conversation to collaborators Jun 16, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Documentation FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done. release-blocker
Projects
None yet
Development

No branches or pull requests

5 participants