cmd/go: warn if implicit GOPATH is equal to GOROOT

[benesch]

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

$ go version
go version devel +ad0ebc3 Tue Mar 27 19:55:14 2018 +0000 linux/amd64

Does this issue reproduce with the latest release?

Yes.

What operating system and processor architecture are you using (go env)?

$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/benesch/.cache/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/benesch/go"
GORACE=""
GOROOT="/home/benesch/go1.10"
GOTMPDIR=""
GOTOOLDIR="/home/benesch/go1.10/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build523055646=/tmp/go-build -gno-record-gcc-switches"

What did you do?

I ran:

$ GOROOT=$HOME/go GOPATH= go env GOPATH
# no output

What did you expect to see?

The warning you normally see when GOROOT is set to the same value as GOPATH, followed by the value of GOPATH:

$ GOROOT=/ GOPATH=/ go env GOPATH
warning: GOPATH set to GOROOT (/) has no effect
/

What did you see instead?

Neither the warning nor the value of GOPATH.

[davecheney]

In your go env output, GOROOT is set to go1.10, probably because this is where you compiled it.

…

On 1 Apr 2018, at 09:16, Nikhil Benesch ***@***.***> wrote: What version of Go are you using (go version)? $ go version go version devel +ad0ebc3 Tue Mar 27 19:55:14 2018 +0000 linux/amd64 Does this issue reproduce with the latest release? Yes. What operating system and processor architecture are you using (go env)? $ go env GOARCH="amd64" GOBIN="" GOCACHE="/home/benesch/.cache/go-build" GOEXE="" GOHOSTARCH="amd64" GOHOSTOS="linux" GOOS="linux" GOPATH="/home/benesch/go" GORACE="" GOROOT="/home/benesch/go1.10" GOTMPDIR="" GOTOOLDIR="/home/benesch/go1.10/pkg/tool/linux_amd64" GCCGO="gccgo" CC="gcc" CXX="g++" CGO_ENABLED="1" CGO_CFLAGS="-g -O2" CGO_CPPFLAGS="" CGO_CXXFLAGS="-g -O2" CGO_FFLAGS="-g -O2" CGO_LDFLAGS="-g -O2" PKG_CONFIG="pkg-config" GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build523055646=/tmp/go-build -gno-record-gcc-switches" What did you do? I ran: $ GOROOT=$HOME/go GOPATH= go env GOPATH # no output What did you expect to see? The warning you normally see when GOROOT is set to the same value as GOPATH, followed by the value of GOPATH: $ GOROOT=/ GOPATH=/ go env GOPATH warning: GOPATH set to GOROOT (/) has no effect / What did you see instead? Neither the warning nor the value of GOPATH. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[AlexRouSg]

@davecheney I believe he is referring to the lack of warning when overriding goroot to be the same as gopath when gopath is unset.

[benesch]

@davecheney I believe he is referring to the lack of warning when overriding goroot to be the same as gopath when gopath is unset.

Yes, exactly. Sorry, I should have been more clear. I don't actually expect setting GOROOT and GOPATH like this to be usable.

[davecheney]

If I recall, that warning is only in the go get/build/install path.

[benesch]

My experiments disagree. It's certainly in the go env path, because it shows up in go env's output for any other bad combination of GOROOT/GOPATH:

$ GOROOT=/ GOPATH=/ go env GOPATH
warning: GOPATH set to GOROOT (/) has no effect
/

$ GOROOT=$HOME/go GOPATH= go env GOPATH
# no output

Based on my source spelunking, it seems like the only command that's exempt is go help:

go/src/cmd/go/main.go

Line 90 in 917c33f

if gopath := cfg.BuildContext.GOPATH; filepath.Clean(gopath) == filepath.Clean(runtime.GOROOT()) {

[bcmills]

I see the same issue with go test:

~$ GOROOT=~/go GOPATH= go test sync
ok      sync    0.496s
~$ GOROOT=~/go GOPATH=$GOROOT go test sync
warning: GOPATH set to GOROOT (/home/bcmills/go) has no effect
ok      sync    (cached)

[rsc]

The implicit GOPATH is never equal to GOROOT.

If the default GOPATH value would have been equal to GOROOT, it is left unset, which avoids creating the problem you are suggesting to warn about.

[benesch]

I see. In that case I have two related grievances. The first is that this behavior is undocumented, as far as I can tell. Nothing in ‘go help gopath’ mentions that the default value for GOPATH is conditional on the value of GOROOT. The second is that this is incredibly confusing for users. If you accidentally compile Go in $HOME/go, your GOROOT will forever prevent your default GOPATH from applying. This isn’t a theoretical problem. We’ve had users fail to compile CockroachDB due to this misconfiguration, and it’s been very difficult, for us and them, to figure out what’s gone wrong. I’m happy to help fix both of these problems, but only if the CLs are actually wanted. I’m also happy to sit back and wait if the plan is to remove GOPATH. But it’s not clear from your response whether you’re uninterested in solving this particular confusion or plan to remove all GOPATH pain another way. Can you advise?

…

On Wed, Apr 18, 2018 at 10:54 AM Russ Cox ***@***.***> wrote: The implicit GOPATH is never equal to GOROOT. If the default GOPATH value would have been equal to GOROOT, it is left unset, which avoids creating the problem you are suggesting to warn about. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#24623 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA15ICg-Jx6DCU8r3sqDEpS2TJZSLYqcks5tp1OVgaJpZM4TCpVO> .

[ianlancetaylor]

The longer term plan is likely to remove GOPATH.

Other than that I think you are describing documentation issues. I don't see any useful code changes that we could make. I think that a warning GOPATH set to GOROOT would be confusing and meaningless when GOPATH is not set.