cmd/go: "go env" returns default value for GOPATH/GOSUMDB/GOPROXY, but not for GOBIN/GO111MODULE/GOTMPDIR

[yaxinlx]

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]

partially a duplicate of #23439.

[jayconrod]

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]

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]

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.

[howjmay]

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

[jayconrod]

@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.