Add go tool directory to PATH when invoking tools

[FiloSottile]

With go/packages, tools need to shell out to the go tool to do their job. It's important that this go tool is the same go tool used by the rest of the editor (which might be based on alternateTools, GOROOT, or PATH, see #1760).

When invoking any tool, the extension should prepend the directory containing the go binary to the PATH environment variable, so the tool will use that go binary.

(I initially reported this as a staticcheck issue when it broke in the standard library: dominikh/go-tools#460.)

[ramya-rao-a]

Is this an issue just with staticcheck, or tools in general?
Isn't it a standard that the go binary lives in whatever the go env GOROOT is pointing to?
If so, then shouldn't tools respect GOROOT first and then look at the path?

[FiloSottile]

This is going to be an issue with any tool based on go/packages, which should be all of them eventually.

Using go env GOROOT is a bit circular, you have to run go to get to go env GOROOT, so it's a bit weird to then change the go binary afterwards. (Like, do you rerun go env GOROOT with the new binary? What if it changes, do you keep going?)

In practice, one should prefer setting PATH so that the right go is first, rather than setting GOROOT, but there is no way to do that in settings.json, is there?

[ramya-rao-a]

Agreed on the circular reference issue if the suggestion was the tools use go env to get the GOROOT, I just assumed that there was a way to get that information without running go first

How about the tools using the value set in the environment variable GOROOT? Shouldn't that work? If yes, then you can use the go.goroot setting in VS Code. The value passed to this setting is used to set the environment variable GOROOT when shelling out any of the Go tools used by this extension.

In practice, one should prefer setting PATH so that the right go is first, rather than setting GOROOT, but there is no way to do that in settings.json, is there?

There are a couple of ways one could do this

• set the right PATH outside of VS Code, so that when you run VS Code, it inherits the right values
• use go.toolsEnvVars setting. Values set here are set as env vars every time the Go plugin shells out to call one of the tools. Need to verify if something like my-path-to-go:${env:PATH} would work. If it doesn't, then that is an easy fix to make

[FiloSottile]

In general, almost no one should be setting the GOROOT env var anymore. The go tool knows the path at which it was built, and uses that as the default GOROOT. That’s why you need to invoke the tool to learn it. Thinking about it, the right way to solve this issue is to discourage use of “go.goroot” or even remove it. Instead there should be a way of setting PATH for both the extension and tools, as they should always be in sync anyway. Does toolsEnvVars apply to the go tool, by the way?

[ramya-rao-a]

I was digging around the code and found that we were already appending the value of GOROOT (as defined by env variable or the go.goroot setting) + /bin into the PATH variable when shelling out Go tools. We did this because cgo expected the go binary to be in the PATH, exactly the same issue as you are seeing.

I have updated this to instead use whatever is the path the extension uses to run the Go binary. This way, we respect the alternate tools value.

Can you try the latest beta version (0.10.3-beta.3) and see if it works as expected for you?

[ramya-rao-a]

This bug fix is now available in the latest update (0.11.0) to the Go extension.