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 env" returns default value for GOPATH/GOSUMDB/GOPROXY, but not for GOBIN/GO111MODULE/GOTMPDIR #42823

Open
yaxinlx opened this issue Nov 25, 2020 · 6 comments
Labels
help wanted NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@yaxinlx
Copy link

yaxinlx commented Nov 25, 2020

What version of Go are you using (go version)?

$ go version
go version go1.15.3 linux/amd64

What did you do?

$ go env GOPROXY
https://proxy.golang.org,direct
$ go env GOSUMDB
sum.golang.org
$ go env GOPATH
/home/d630/go
$ go env GOBIN

$ go env GO111MODULE

$ go env GOTMPDIR

$ 

None of these envs are set specifically.

What did you expect to see?

I expect go env GOBIN to be evaluated as <gopath>/bin in a shell script.

What did you see instead?

go env GOBIN is evaluated as blank.

@mvdan
Copy link
Member

mvdan commented Nov 25, 2020

partially a duplicate of #23439.

@jayconrod
Copy link
Contributor

Closing as a duplicate of #23439.

For GOBIN, we'll likely fix #23439 after support for GOPATH builds is removed. In GOPATH mode, the logic that determines where binaries are installed when GOBIN is not set is surprisingly complicated. It depends on the location of the packages being installed within the root directories (GOROOT and GOPATH) as well as GOOS, GOARCH, and probably some other variables I'm forgetting. go env GOBIN frequently won't give an accurate answer when GOBIN is not set.

For GO111MODULE, the empty string is a valid value. In 1.15, it's equivalent to auto. In 1.16, it's equivalent to on.

GOTMPDIR probably could print a default, though I'm not sure if that would be useful in many cases.

@yaxinlx
Copy link
Author

yaxinlx commented Nov 30, 2020

For GO111MODULE, the empty string is a valid value. In 1.15, it's equivalent to auto. In 1.16, it's equivalent to on.

It is true that an empty string is a valid GO111MODULE value, just like empty strings for GOPATH/GOSUMDB/GOPROXY. But the truth doesn't mean the inconsistency is a good design. I don't think it is harmful to let go env GO111MODULE return auto in go 1.15 and on in 1.16 if GO111MODULE is not set (or always interpret a blank GO111MODULE as auto).

GOTMPDIR probably could print a default, though I'm not sure if that would be useful in many cases.

Any harmfulness to make a consistency here?

@jayconrod
Copy link
Contributor

My interpretation of the issue was this was mainly about GOBIN. There's no harm in printing defaults for the other variables though. I'll reopen the issue.

@jayconrod jayconrod reopened this Nov 30, 2020
@jayconrod jayconrod added help wanted NeedsFix The path to resolution is known, but the work has not been done. labels Nov 30, 2020
@jayconrod jayconrod added this to the Unplanned milestone Nov 30, 2020
@howjmay
Copy link
Contributor

howjmay commented Dec 15, 2020

so should we simply print GOBIN as <gopath>/bin

@jayconrod
Copy link
Contributor

@howjmay It's more complicated than that:

For GOBIN, we'll likely fix #23439 after support for GOPATH builds is removed. In GOPATH mode, the logic that determines where binaries are installed when GOBIN is not set is surprisingly complicated. It depends on the location of the packages being installed within the root directories (GOROOT and GOPATH) as well as GOOS, GOARCH, and probably some other variables I'm forgetting. go env GOBIN frequently won't give an accurate answer when GOBIN is not set.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Development

No branches or pull requests

4 participants