"go.toolsManagement.go" setting is not respected while installing tools

[ahmetb]

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

Version Information

• Run go version to get version of Go from the VS Code integrated terminal.
  • go version go1.20.3 darwin/arm64
• Run gopls -v version to get version of Gopls from the VS Code integrated terminal.
  • not installed yet N/A
• Run code -v or code-insiders -v to get version of VS Code or VS Code Insiders.
  • 1.77.3 704ed70d4fd1c6bd6342c436f1ede30d1cff4710 arm64
• Check your installed extensions to get the version of the VS Code Go extension
  • v0.38.0
• Run Ctrl+Shift+P (Cmd+Shift+P on Mac OS) > Go: Locate Configured Go Tools command.

Checking configured tools....
GOBIN: undefined
toolsGopath: 
gopath: /Users/abalkan/go
GOROOT: /opt/homebrew/Cellar/go/1.20.3/libexec
PATH: /opt/homebrew/Cellar/go/1.20.3/libexec/bin:/Users/abalkan/.volta/bin:/Users/abalkan/.cargo/bin:/Users/abalkan/go/bin:/Users/abalkan/.krew/bin:/Users/abalkan/workspace/dotfiles/bin:/opt/homebrew/share/google-cloud-sdk/bin:/opt/homebrew/opt/python/libexec/bin:/opt/homebrew/bin:/opt/homebrew/sbin:/usr/local/bin:/System/Cryptexes/App/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin:/export/content/granular/bin:/opt/homebrew/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin:/Users/abalkan/gotools/bin:/opt/homebrew/opt/fzf/bin:/Users/abalkan/.local/bin
PATH (vscode launched with): /Users/abalkan/.volta/bin:/Users/abalkan/.cargo/bin:/Users/abalkan/go/bin:/Users/abalkan/.krew/bin:/Users/abalkan/workspace/dotfiles/bin:/opt/homebrew/share/google-cloud-sdk/bin:/opt/homebrew/opt/python/libexec/bin:/opt/homebrew/bin:/opt/homebrew/sbin:/usr/local/bin:/System/Cryptexes/App/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin:/export/content/granular/bin:/opt/homebrew/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin:/Users/abalkan/gotools/bin:/opt/homebrew/opt/fzf/bin:/Users/abalkan/.local/bin

	go:	/opt/homebrew/Cellar/go/1.20.3/libexec/bin/go: go version go1.20.3 darwin/arm64

	gotests:	not installed
	gomodifytags:	not installed
	impl:	not installed
	goplay:	not installed
	dlv:	/Users/abalkan/go/bin/dlv	(version: v1.20.2 built with go: go1.20.3)
	staticcheck:	not installed
	gopls:	not installed

go env
Workspace Folder (kubectl-in): /Users/abalkan/workspace/kubectl-in
	GO111MODULE=""
	GOARCH="arm64"
	GOBIN=""
	GOCACHE="/Users/abalkan/Library/Caches/go-build"
	GOENV="/Users/abalkan/Library/Application Support/go/env"
	GOEXE=""
	GOEXPERIMENT=""
	GOFLAGS=""
	GOHOSTARCH="arm64"
	GOHOSTOS="darwin"
	GOINSECURE=""
	GOMODCACHE="/Users/abalkan/go/pkg/mod"
	GONOPROXY="none"
	GONOSUMDB="*"
	GOOS="darwin"
	GOPATH="/Users/abalkan/go"
	GOPRIVATE="*"
	GOPROXY="custom-goproxy.redacted.com"
	GOROOT="/opt/homebrew/Cellar/go/1.20.3/libexec"
	GOSUMDB="off"
	GOTMPDIR=""
	GOTOOLDIR="/opt/homebrew/Cellar/go/1.20.3/libexec/pkg/tool/darwin_arm64"
	GOVCS=""
	GOVERSION="go1.20.3"
	GCCGO="gccgo"
	AR="ar"
	CC="cc"
	CXX="c++"
	CGO_ENABLED="1"
	GOMOD="/dev/null"
	GOWORK=""
	CGO_CFLAGS="-O2 -g"
	CGO_CPPFLAGS=""
	CGO_CXXFLAGS="-O2 -g"
	CGO_FFLAGS="-O2 -g"
	CGO_LDFLAGS="-O2 -g"
	PKG_CONFIG="pkg-config"
	GOGCCFLAGS="-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/vs/tl1gmc7532v57hs_zc10y0pw0029gx/T/go-build2614520022=/tmp/go-build -gno-record-gcc-switches -fno-common"

Share the Go related settings you have added/edited

  "go.buildOnSave": "package",
  "go.useLanguageServer": true,
  "go.lintOnSave": "off",
  "go.toolsManagement.autoUpdate": true,
  "go.toolsManagement.go": "env -u GOPRIVATE -u GOPROXY -u GONOPROXY -u GOSUMDB go",

Describe the bug

I'm behind a corporate proxy in terms of the imports my Go code imports. So I almost always have GOPROXY, GOPRIVATE, GONOPROXY env vars set in my terminal.

However I want to install the vscode-go tools (gopls, staticcheck etc) from the internet, without picking up the GOPROXY etc.

I use the following setting to customize the go command that's used for "installing Go tools" to remove these env vars:

"go.toolsManagement.go": "env -u GOPRIVATE -u GOPROXY -u GONOPROXY -u GOSUMDB go",

However, it still just picks up the /opt/homebrew/Cellar/go/1.20.3/libexec/bin/go program.

Steps to reproduce the behavior:

1. Nuke tools go clean -modcache + rm -rf ~/go/bin
2. Set export GOPROXY=nonexisting.domain in the shell
3. Type code . from this shell to launch vscode with GOPROXY env var set.
4. Open a Go file, accept the prompt to install Go tools
5. Observe that the cmd in the error still is not picking up the custom command in the OUTPUT window (this error is from my goproxy):

...
Installing github.com/cweill/gotests/gotests@v1.6.0 FAILED
{
 "killed": false,
 "code": 1,
 "signal": null,
 "cmd": "/opt/homebrew/Cellar/go/1.20.3/libexec/bin/go install -v github.com/cweill/gotests/gotests@v1.6.0",
 "stdout": "",
 "stderr": "go: github.com/cweill/gotests/gotests@v1.6.0: github.com/cweill/gotests/gotests@v1.6.0: reading https://custom-goproxy.redacted.com/github.com/cweill/gotests/gotests/@v/v1.6.0.info: 404 Not Found\n\tserver response: For multiproduct com.github.cweill.gotests:gotests, versions 1.6.0, v1.6.0, 1.6.0+incompatible and v1.6.0+incompatible are not active.\n"
}
...

Screenshots or recordings

[hyangah]

The go.toolsManagement.go field expects a path to the executable (https://github.com/golang/vscode-go/blob/fa820d45d7b9217e949c21ffd13268e20c7e0ee4/src/goInstallTools.ts#L101C1-L105) and env ... go wouldn't pass the executable bit test.

@ahmetb Is it possible to write a shell script (executable) and place the script path?

[ahmetb]

@hyangah I see now. Why does it silently fail and swallow the error? It can solve my problem but cost me quite some time to see that. I put stuff like date there, thinking it does ~exec.LookPath query, and now I see it expects absolute paths (docs don't make this clear).

Can we

1. fix docs to match behavior
2. not swallow the error message and resort to the default setting?

If someone's changing this field it's not great to ignore their intent.

[adonovan]

Can we [...] not swallow the error message and resort to the default setting?

Yes, that seems like the appropriate change.

[gopherbot]

Change https://go.dev/cl/501056 mentions this issue: src/goInstallTools: report when go.toolsManagement.go is not executable