adding go runtime base to PATH interacts very badly with goenv

[rbtcollins]

What version of Go, VS Code & VS Code Go extension are you using?

$ code -v
1.52.1
ea3859d4ba2f3e577a159bc91e3074c5d85c0523
x64

• Check your installed extensions to get the version of the VS Code Go extension
  • 0.20.0

Consider this path:

echo $PATH
/home/robertc/.pyenv/plugins/pyenv-virtualenv/shims:/home/robertc/.pyenv/shims:/home/robertc/.goenv/versions/1.15.6/bin:/home/robertc/.vscode-server/bin/ea3859d4ba2f3e577a159bc91e3074c5d85c0523/bin:/home/robertc/.pyenv/plugins/pyenv-virtualenv/shims:/home/robertc/.pyenv/shims:/home/robertc/.goenv/shims:/home/robertc/.goenv/bin:/home/robertc/.cargo/bin:/home/robertc/.pyenv/bin:/home/robertc/bin:/home/robertc/.vscode-server/bin/ea3859d4ba2f3e577a159bc91e3074c5d85c0523/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin

Note that go 1.15.6 is in the path.

In .vscode/settings.json:

    "go.goroot": "/home/robertc/.goenv/versions/1.14.13",
    "go.gopath": "/home/robertc/go/1.14.13",

But yet, from the same directory from a shell not spawned under vs-code:

$ goenv local
1.14.13
$ go version
go version go1.14.13 linux/amd64

As far as I can tell, the in-vscode tool invocation is using the override 1.14.13 root/path etc; the shell is not only because vscode is adding 1.15.6 to the path (which you can tell is vscode because it is before the vscode-server entry in the path).

Making this optional would be a great help to those of us using goenv to manage multiple go versions and switch between them - we usually have the right GOROOT, a sane GOPATH etc, and need to have the shim entry in PATH, not the runtime base.

[hyangah]

@rbtcollins thanks for the report.
I want to understand what's going on here.

Is your goal to use a different version (1.14.13) of Go from your integrated terminal while your extension is using 1.15.6 for the language server, analysis, testing, and debugging by default?

Or was the intention to use 1.14.13 for the project, but the extension picked up 1.15.6 despite you set 1.14.13 as the go.goroot (that's not how I expected the extension to behave so it's likely a bug).

[rbtcollins]

The goal was to use 1.14.13 for the project, for the toolchain, and for the integrated terminal.

My desktop is a Windows 10 Professional. The Go environment is an Ubuntu VM being accessed via the Remote-SSH extension, if that helps.

[hyangah]

@rbtcollins My apologies. This issue fell through the cracks and I failed to follow up. :-(

Can you please verify if the in-vscode tool invocation is actually using the 1.14.13 ?

• Set "go.logging.level": "verbose" from the setting -> "Developer: Reload Window" from Command Palette -> "Developer: Toggle Developer Tools" -> Filter by "Go [V]" -> Share the output.

• Run Go: Locate Configured Go Tools command and check the output (GOROOT).

The PATH modification for shell happens only when the go binary to be used by the extension can't be found in PATH. I originally thought this was related to #776 (go.goroot doesn't mutate GOROOT env var), but in this case, it seems like go.goroot wasn't used to pick the right go binary. So it looks different.

[gopherbot]

Change https://golang.org/cl/336409 mentions this issue: package.json: add go.terminal.activateEnvironment setting

[huanghantao]

I have the same problem, what is the solution now? I can't get goenv and vscode to work properly using SSH remote.

[hyangah]

@huanghantao As shown in the cl title of the last comment, go.terminal.activateEnvironment setting was added to disable.