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

benesch · 2018-03-31T23:16:10Z

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.

The text was updated successfully, but these errors were encountered:

davecheney · 2018-03-31T23:35:49Z

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 · 2018-03-31T23:50:45Z

@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 · 2018-03-31T23:57:06Z

@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 · 2018-04-01T00:16:13Z

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

benesch · 2018-04-01T00:24:22Z

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 · 2018-04-02T19:22:05Z

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 · 2018-04-18T14:53:08Z

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 · 2018-04-18T15:09:59Z

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 · 2018-04-18T16:12:04Z

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.

benesch mentioned this issue Mar 31, 2018

Further improve GOPATH detection in Makefile cockroachdb/cockroach#24387

Closed

benesch changed the title ~~cmd/go: GOROOT of $HOME/go not handled correctly~~ cmd/go: GOROOT of $HOME/go does not produce warning Mar 31, 2018

bcmills changed the title ~~cmd/go: GOROOT of $HOME/go does not produce warning~~ cmd/go: warn if GOROOT is set to implicit GOPATH Apr 2, 2018

bcmills changed the title ~~cmd/go: warn if GOROOT is set to implicit GOPATH~~ cmd/go: warn if implicit GOPATH is equal to GOROOT Apr 2, 2018

bcmills added the NeedsFix The path to resolution is known, but the work has not been done. label Apr 2, 2018

bcmills added this to the Go1.11 milestone Apr 2, 2018

rsc closed this as completed Apr 18, 2018

golang locked and limited conversation to collaborators Apr 18, 2019

gopherbot added the FrozenDueToAge label Apr 18, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

benesch commented Mar 31, 2018

davecheney commented Mar 31, 2018 via email

AlexRouSg commented Mar 31, 2018

benesch commented Mar 31, 2018

davecheney commented Apr 1, 2018

benesch commented Apr 1, 2018 •

edited

bcmills commented Apr 2, 2018

rsc commented Apr 18, 2018

benesch commented Apr 18, 2018 via email

ianlancetaylor commented Apr 18, 2018

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

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

Comments

benesch commented Mar 31, 2018

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

Does this issue reproduce with the latest release?

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

What did you do?

What did you expect to see?

What did you see instead?

davecheney commented Mar 31, 2018 via email

AlexRouSg commented Mar 31, 2018

benesch commented Mar 31, 2018

davecheney commented Apr 1, 2018

benesch commented Apr 1, 2018 • edited

bcmills commented Apr 2, 2018

rsc commented Apr 18, 2018

benesch commented Apr 18, 2018 via email

ianlancetaylor commented Apr 18, 2018

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

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

benesch commented Apr 1, 2018 •

edited