x/tools/go/packages: use GOROOT when running go list

[marwan-at-work]

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

Tip: go version devel +1b870077c8 Fri Aug 3 17:21:10 2018 +0000 darwin/amd64

Does this issue reproduce with the latest release?

Yes, go1.11beta3

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

GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/208581/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/208581/go"
GOPROXY=""
GORACE=""
GOROOT="/Users/208581/Desktop/gosource/go"
GOTMPDIR=""
GOTOOLDIR="/Users/208581/Desktop/gosource/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
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 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/n4/35bgdnkd6vlgqrdzbyl0x1ycmhcndx/T/go-build218967352=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

Having go 1.10.3 installed in my bin, go1.11beta3 installed from source and not in PATH,
I tried running packages.Load(nil, "github.com/mitchellh/go-homedir") with go1.11beta3 as an example to find a module-enabled package.

What did you expect to see?

I expected to see a built Package with its files pointing to GOPATH/pkg/mod/...

What did you see instead?

package not found error.

The reason is that the Packages cmd just runs go and if you have multiple go versions installed (go, go1.11beta3, and maybe a separate go built from source but in PATH), then it will not use the appropriate one. This is especially important if you have editors (such as VSCode) with their GOROOT configured to something that is not in PATH, then the Packages tool should still work with it.

[ianlancetaylor]

CC @alandonovan @ianthehat @matloob

[ianthehat]

In #27785 @jimmyfrasche suggests we have an environment variable that specifies the go binary to use. I think I prefer that approach to trusting the GOROOT, it also allows specifying binaries that are not called go (like vgo or go1.11), if we all agree, then we can spend a month or so bikeshedding about the name of the environment variable :)

[jimmyfrasche]

Sorry for the duplicate. When I was skimming issue titles, this didn't register as the same problem.

Something I thought of this morning: If we go with an env var for selecting which go tool, should the go tool itself be aware of it?

It doesn't matter for most of the subcommands, but some invoke other programs which may in turn need to invoke the go tool directly or via go/packages. If it doesn't set it, you'd need to do something like

GOCMD=go1.12beta1 go1.12beta1 generate

[marwan-at-work]

@jimmyfrasche does that mean GOROOT here is a better option? I'm happy w/ either one.

[ianthehat]

I agree it would be nice if the go tool ran tools with GOCMD set, and that was part of the reason I think it's a better choice. If the go command is not called go or not in a $GOROOT/bin directory, then it would not be able to do that. It can always set GOCMD to itself though.

[jimmyfrasche]

@alandonovan since #28043 is closed, does that mean this should be closed, too? The workarounds provided there apply here.

[ianthehat]

I think so, the workarounds are good enough, and if GOCMD is not going to be accepted and standardized, we should not use it here either.