Allow saving symbolic path as Go environment path

[ansidev]

Is your feature request related to a problem? Please describe. $ which go /usr/local/bin/go

$ ll $(which go) lrwxr-xr-x 26 ansidev 14 Apr 09:43 /usr/local/bin/go -> ../Cellar/go/1.18.1/bin/go

(Go was installed by brew)

The Go executable path is /usr/local/bin/go and this is a symbolic link that links to usr/local/Cellar/go/1.18.1/bin/go.

Currently, VSCode Go extension save the Go environment path as usr/local/Cellar/go/1.18.1/bin/go when I select /usr/local/bin/go.

Describe the solution you'd like As a developer, I want VSCode to save the Go environment path as /usr/local/bin/go instead of the real path usr/local/Cellar/go/1.18.1/bin/go so I do not need to update the Go environment path each time I update the Go version via brew.

[hyangah]

As a developer, I want VSCode to save the Go environment path as /usr/local/bin/go instead of the real path usr/local/Cellar/go/1.18.1/bin/go so I do not need to update the Go environment path each time I update the Go version via brew.

The extension resolves GOROOT once when it starts and uses GOROOT/bin/go to ensure the same go is used during the session. The info is in memory, and doesn't persist any where. When you restart the window or run "Developer: Restart Extension Host" or "Developer: Reload Window" commands, the info will be recomputed.

Or, do you want to avoid restarting the vscode window at all after updating the go version via brew? I am afraid that's difficult to support - the extension caches a variety of info (GOROOT/go version/selection of tools based on go version/...) determined during the start time, and invokes a language server that switches functionalities depending on the go version. Tracking all of them and supporting the dynamic change will be a major change.

[ansidev]

As a developer, I want VSCode to save the Go environment path as /usr/local/bin/go instead of the real path usr/local/Cellar/go/1.18.1/bin/go so I do not need to update the Go environment path each time I update the Go version via brew.

The extension resolves GOROOT once when it starts and uses GOROOT/bin/go to ensure the same go is used during the session. The info is in memory, and doesn't persist any where. When you restart the window or run "Developer: Restart Extension Host" or "Developer: Reload Window" commands, the info will be recomputed.

Or, do you want to avoid restarting the vscode window at all after updating the go version via brew? I am afraid that's difficult to support - the extension caches a variety of info (GOROOT/go version/selection of tools based on go version/...) determined during the start time, and invokes a language server that switches functionalities depending on the go version. Tracking all of them and supporting the dynamic change will be a major change.

Currently, I've installed multiple versions of Go on my laptop: 1.15-1.18 and the default Go version is 1.18.

Problem 1: I have tested this script:

1. Open VS Code.
2. Close all VS Code windows.
3. Open or create a new Go project: Project A.
4. Set Go env path to 1.18 (same as the path I got from the terminal).
5. At this time, only one VS windows (Go project A) is opened. Quit and reopen VS Code.
6. The project A is opened with Go version 1.18.
7. Open or create another Go project (Project B), and set Go version to a different Go version, ex. 1.17.
8. At this time, we have 2 VS windows (Go project A (Go 1.18) and B (1.17)) is opened. Quit and reopen VS Code.

Two project A & B is opened with configured Go versions, and these configuration have different GOROOT. How does the extension save them?

Problem 2:

Currently, the extension save the real path of go. So the Go path must be configured in VS Code manually by the developers after they updates Go version manually (via the install package or terminal command).

For example:

1. VS Code Go environment path: /usr/local/Cellar/go/1.18/bin/go
2. Developer run brew command to upgrade Go to 1.18.1.
3. Developer must update VS Code Go environment path.

This is not good behaviour.

I suggest some solutions: auto-scan available paths of Go on choosing the Go environment path, auto-suggest if the Go version is updated (optional, can be toggled).

[hyangah]

@ansidev

2. Set Go env path to 1.18"

Can you clarify what you did to set Go env path to 1.18? The extension uses PATH (on linux/mac) or Path (on windonws) environment variable the VS Code was launched with. So, most people don't have to configure the location of Go from the extension.

The extension offers an option to choose a session-specific Go version for users who need to switch among different Go versions frequently, which is the Choose Go Environment option from Go status bar. For that functionality, the extension indeed stores the path to the Go binary in a persistent store for the window. Were you using this option?

Go path must be configured in VS Code manually

AFAIK, that's not true. The extension finds go from the PATH. So, if /usr/local/bin is in your PATH set (login shell), the extension picks Go from /usr/local/bin/go. You can check what PATH environment the extension saw when it was started by running "Go: Locate Configured Go Tools" command - that will be shown in PATH (vscode launched with): ... line.

Currently the extension already implements 5 different mechanisms for finding where to find the go binary:

1. from the PATH environment variable the VS Code finds out (I think it's the path configured in your login shell) TIP: for quickly check a directory with different Go version, you can also open a new VS Code window with a different PATH and influence the extension of the new window to use the PATH. E.g. PATH=$HOME/sdk/go1.14/bin:$PATH code . will open a new VS Code window using the go in $HOME/sdk/go1.14/bin directory.
2. from the specific path users configured using the Choose Go Environment menu
3. from the GOROOT/bin configured with either the GOROOT environment variable or "go.goroot" setting which can be in the user-profile scope (applied to all windows), or in the workspace-scope (applied to a single window)
4. from the path configured with "go.alternateTools": { "go": "<path_to_go> }` which can be again specified in the user-profile scope or in the workspace-scope.
5. if all fail, the extension tries the commonly used paths like /usr/local/bin/go as written in https://github.com/golang/vscode-go/blob/master/src/utils/pathUtils.ts#L108-L111 (I think symlinks don't qualify the test though)

I suggest some solutions: auto-scan available paths of Go on choosing the Go environment path, auto-suggest if the Go version is updated (optional, can be toggled).I suggest some solutions: auto-scan available paths of Go on choosing the Go environment path, auto-suggest if the Go version is updated (optional, can be toggled).

As I commented in #2184, auto-scanning and running arbitrary binary raises some concerns (both for security and for performance) unless it's done very carefully.

I think you can also turn off the version check by turning off using go.toolsManagement.checkForUpdates

When extension determines the go's location, it also tries to affect the PATH used in the integrated terminal (however, I think there is a bug on Mac which fails to apply to all integrated terminals correctly) by prepending ${GOROOT}/bin/go to the PATH environment. Users who don't like this behavior (e.g. want gvm or direnv to manage PATH) can prevent this behavior by configuring "go.terminal.activateEnvironment": false.

[ansidev]

@hyangah

Set Go env path to 1.18 (same as the path I got from the terminal).

I mean Choose Go Environment in VS Code Go.

Go path must be configured in VS Code manually

It may be my fault. Let me check this later!

You mentioned 5 different mechanisms for finding where to find the go binary, what is the priority of each mechanism?

[hyangah]

You mentioned 5 different mechanisms for finding where to find the go binary, what is the priority of each mechanism?

I think roughly 2>3>4>1>5, but it's possible I misremember the code path (& possible bugs) The relevant code path is https://github.com/golang/vscode-go/blob/e599c1ab941c35b986c55771bb9dd73d2f7f58b2/src/utils/pathUtils.ts#L56

My personal recommendation is 1 (no setting, but my login shell).

I use Choose Go Environment (option 2) when I need to test versions different from my default Go determined with my PATH.

I use option 3 when working with the Go project.

Option 4 is better to avoid if possible.

[gopherbot]

Change https://go.dev/cl/561997 mentions this issue: extension/src/goMain: remove unnecessary env var update