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

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

Closed
marwan-at-work opened this issue Aug 7, 2018 · 7 comments
Closed

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

marwan-at-work opened this issue Aug 7, 2018 · 7 comments
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@marwan-at-work
Copy link
Contributor

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.

@gopherbot gopherbot added this to the Unreleased milestone Aug 7, 2018
@ianlancetaylor ianlancetaylor added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Aug 7, 2018
@ianlancetaylor
Copy link
Contributor

CC @alandonovan @ianthehat @matloob

@ianthehat
Copy link

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
Copy link
Member

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
Copy link
Contributor Author

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

@ianthehat
Copy link

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
Copy link
Member

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

@ianthehat
Copy link

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

5 participants