Open stamblerre opened 4 years ago
For standard library development I use toolsGopath to keep separate builds of the tools in case tip introduced any incompatibility. How would that use case be handled if the option is deprecated?
I believe that @hyangah has discovered that the whole "Your GOROOT has changed, analysis tools may need to be recompiled" warning (which I assume is what you're referring to?) is not really valid/necessary anymore. The majority (all?) tools should still work in codebases that use different Go versions without being recompiled.
In any case, you'd still be able to set different GOBIN
s in different workspaces. My thinking on this whole topic is really that we should deprecate all settings and make go.toolsEnvVars
the only option (maybe with a better name).
There are far too many ways to set a
GOPATH
in this extension. We need to centralize them and provide users with common workflows to follow. Some thoughts:go.toolsGopath
for Go versions over 1.11. Modules renders the reasoning behind this setting obsolete.go.gopath
vs. settingGOPATH
ingo.toolsEnvVars
. Which one overrides the other? I have no idea what happens right now.GOBIN
ingo.toolsEnvVars
?go.inferGopath
makes sense in a modules world.PATH
and only fallback toGOPATH/bin
orGOBIN
if the binary is not on thePATH
.