installation: allow to use different build settings for tools installation

[hyangah]

I thought I already filed an issue to track this, but obviously I didn't?

Recently we observed multiple cases where reusing the project build configuration for tool installation is not desirable. Example cases are

• Users need to use an old version of Go which is older than the minimum version tools require. (gopls installation works only with go 1.13+ #66, all: establish version support & release policy #388)
• Users need to use different environment variables. (TinyGo integration #628 - note: for GOOS/GOARCH, we probably need to override them with GOHOSTOS/GOHOSTARCH or simply unset them )
• Users need to use special build flags. (Add -insecure to go get command when getting additional tools #814)

Currently, the settings that are involved in tool installation are

• "go.goroot","go.alternateTools"."go", and the version chosen by go.environment.choose command: determines the Go version
• "go.toolsGopath": determines the tool installation path (${go.toolsGopath}/bin).
• "go.toolsEnvVars": determines the environment vars. This is also used for tools execution such as go build, gopls, dlv...

I propose to introduce a new setting that takes an object

"go.toolsInstall": {
   "go": "",  // path to the go command 
   "env": {},  // extra env vars to apply
   "flags": [],  // extra flags users want to pass e.g. -insecure
}

When they are not set, we fall back to the old behavior.
This setting is machine scope (https://code.visualstudio.com/api/references/contribution-points).

We also deprecate "go.toolsGopath" sometime next year.

cc @suzmue @stamblerre @ianthehat @ramya-rao-a

[ramya-rao-a]

go.toolsEnvVars applies to all the Go tools that are run by the extension. In the new proposal, you have flags. Do you plan to apply these flags to all the Go tools or are you thinking of these flags to apply only to the go cmd?

[ramya-rao-a]

Also, the new proposal does not have a counterpart to go.toolsGopath. What is our answer for folks who used this to ensure that the Go tools used by the extension dont pollute their gopath?

[hyangah]

@ramya-rao-a Thanks for the comment.

go.toolsEnvVars applies to all the Go tools that are run by the extension.

Yes, I am proposing not to apply the env vars if go.toolsInstall.env is set.
go.toolsEnvVars were introduced to set environment variables necessary to build user projects
(cross-compile, different compilation flags, etc. See microsoft/vscode-go#932, microsoft/vscode-go#632). Most of those environment
variables are not applicable to the go command invoked for tool installation.

GOPROXY and HTTP-related env vars may be applicable though. During migration,
we can prompt users and suggest new settings when users invoke tool installation and
we see the use of go.toolsEnvVars.

In the new proposal, you have flags. Do you plan to apply these flags to all the Go tools or are you thinking of these flags to apply only to the go cmd?

Yes, this setting applies only to the go command used to install the tools. So, these flags are only go command flags.

Also, the new proposal does not have a counterpart to go.toolsGopath. What is our answer for folks who used this to ensure that the Go tools used by the extension dont pollute their gopath?

The tool installation is now done in module-aware mode and shouldn't pollute GOPATH except downloading modules and checksum in GOPATH/pkg. If users find they want to use separate module caches, they can configure by setting the env field.

[gopherbot]

Change https://go.dev/cl/387956 mentions this issue: package.json: add go.toolsManagement.go

[hyangah]

v0.32.0 will introduce a new go.toolsManagement.go.
Not sure about env and flags at this moment.

Q. Users need to use different environment variables?
A. The issue in #628 was from the GOOS/GOARCH/GOROOT. We already unset them for tools installation.

Q. Users need to use special build flags.
A. The issue #814 was about -insecure flag, but that flag is deprecated.

It's possible that users may need different env vars & flags - in that case, for now users can wrap the go command in a script and place the script in the go.toolsManagement.go.