Open radcool opened 3 years ago
@radcool Thanks for the bug report.
This is clearly a bug - the heuristic was written before the remote development was possible. We need to rewrite this.
@heschik suggested the tool update is still desirable if the tools were built with older versions of go (to take advantage of new features) or if the tools were too old. Now we have the go version
command to inspect what version of go was used to build the tool, and go version -m
to check the tool's version. So, we don't need the heuristic.
(Issue opened after advice from @hyangah on Gophers Slack in this thread)
What version of Go, VS Code & VS Code Go extension are you using?
go version
to get version of Gogopls -v version
to get version of Gopls if you are using the language server.code -v
orcode-insiders -v
to get version of VS Code or VS Code Insidersgo env
to get the go development environment detailsShare the Go related settings you have added/edited
Run
Preferences: Open Settings (JSON)
command to open your settings.json file. Share all the settings with thego.
or["go"]
orgopls
prefixes.Describe the bug
My main machine is running Archlinux with Go installed with pacman (so stuff installed in
/usr/lib/go
), but I often do development on a remote VM at work, which is running Fedora 33 with a manually-installed Go (so stuff is in/usr/local/go
). Whenever I switch from local development to remote development (and vice versa) the Go extension pops up a message the current goroot is different than before, and then offers to update the Go tools.From my point of view these two Go installations are completely unrelated so I don't see any benefit to continuously offer to update them solely based on the fact that they are located in different goroots.
Steps to reproduce the behavior:
Jump from local to remote SSH development on the same VS Code editor on a local and remote machine where the goroot of both Go installations is different.
Screenshots or recordings