(golang extensions) Linux<>Linux, uses client home instead of remote home #2981
Comments
|
the only workaround i found for this is to set |
|
Given the discussion in #2576 I conclude that the go extension revert the machine scope for some settings. @sandy081 I assume this has been addressed on the VS Code side with the introduction of the scope
|
|
Yes, looks to me Go extension shall fix this by making the setting Please file issue against Go extension. |
|
Moved to Go extension repo. |
|
oh thank you @sandy081 ! didnt even know that was possibe to move issues |
stamblerre
added
needs-investigation
vscode-remote
|
okay yeah this is still an issue While it clearly states that there is a way to change it, it is still an issue as it still utilizes the Clients home directory when it should use the remotes home directory, (in this case, it is |
By setting them machine-overridable, client user values can be ignored in remote settings and the remote side can pick up the right value. I think go.alternateTools should be machine-overridable as well but will get to it next time. Manually tested by 1) setting go.gopath in user settings, vsce package, connecting to the remote host, sideloading vsix (do it after connecting, so the remote host can pick up the vsix), and checking the GOPATH with "Go: Current GOPATH" and also, by reinstalling all tools. 2) setting go.gopath in workspace settings and checking it's still doable. Fixes microsoft#2981 Updates microsoft#2576 Change-Id: I3390355d186280c13353d210adb51edfa3858032
|
I made a change in the new repo. (https://go-review.googlesource.com/c/vscode-go/+/236539). Once the cl is approved and merged, we will release a nightly version and ping this thread to ask to test. cc/ @ramya-rao-a |
By setting them machine-overridable, client user values can be ignored in remote settings and the remote side can pick up the right value. I think go.alternateTools should be machine-overridable as well but will get to it next time. Manually tested by 1) setting go.gopath in user settings, vsce package, connecting to the remote host, sideloading vsix (do it after connecting, so the remote host can pick up the vsix), and checking the GOPATH with "Go: Current GOPATH" and also, by reinstalling all tools. 2) setting go.gopath in workspace settings and checking it's still doable. Fixes microsoft/vscode-go#2981 Updates microsoft/vscode-go#2576 Change-Id: I3390355d186280c13353d210adb51edfa3858032 Change-Id: I3390355d186280c13353d210adb51edfa3858032 GitHub-Last-Rev: 0463b84 GitHub-Pull-Request: #175 Reviewed-on: https://go-review.googlesource.com/c/vscode-go/+/236539 Reviewed-by: Rebecca Stambler <rstambler@golang.org>
|
This change is now available in Go Nightly (2020.6.716). Please test if it works as you expected. If it works as expected, I hope to get it included in the next stable release (0.15.0). |
|
Unable to test as of this moment, as i have no compatible remotes availible to me at the moment, will test when i get the chance |
Steps to Reproduce:
Does this issue occur when you try this locally?: No
Does this issue occur when you try this locally and all extensions are disabled?: Yes??
when i am updating the tools
i operate over lan by remote accessing my dev server alot
the golang extension messes with this because when you "update the tools" it appears to use the client gopath instead of the remote gopath
my personal gopath is
/home/merith/.gomy remote gopath is
/home/developer/goboth client and server are running go 1.13.6 and the latest updates of both extensions.
The text was updated successfully, but these errors were encountered: