Remote-WSL does not find go even if it is on $PATH

[davidovich]

Environment:

Version: 1.34.0-insider (user setup)
Commit: daf71423252a707b8e396e8afa8102b717f8213b
Date: 2019-05-06T22:08:08.969Z
Electron: 3.1.8
Chrome: 66.0.3359.181
Node.js: 10.2.0
V8: 6.6.346.32
OS: Windows_NT x64 10.0.17763

Problem: go is not found even if it is on path, even though the extension tells me otherwise.

PATH=/home/david/bin:/home/david/go/bin:/home/linuxbrew/.linuxbrew/bin:/home/linuxbrew/.linuxbrew/sbin:/home/david/.vscode-remote/bin/daf71423252a707b8e396e8afa8102b717f8213b/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/c/ProgramData/DockerDesktop/version-bin:/c/Program Files/Docker/Docker/resources/bin: [truncated...]

My go installation is managed by linuxbrew in WSL.

Note that without the go.goroot setting, nothing works ( go and tools are not found and I am prompted with Cannot find "go" binary. Update PATH or GOROOT appropriately ). I would expect that the extension find go without setting the go.goroot.

workbench.main.js:238 [Extension Host] rejected promise not handled within 1 second: Error: Cannot find "go" binary. Update PATH or GOROOT appropriately
t.log @ workbench.main.js:238
workbench.main.js:238 [Extension Host] stack trace: Error: Cannot find "go" binary. Update PATH or GOROOT appropriately
	at Object.updateGoPathGoRootFromConfig (/home/david/.vscode-remote/extensions/ms-vscode.go-0.10.2/out/src/goInstallTools.js:401:31)
	at activate (/home/david/.vscode-remote/extensions/ms-vscode.go-0.10.2/out/src/goMain.js:59:22)
	at Function._callActivateOptional (/home/david/.vscode-remote/bin/daf71423252a707b8e396e8afa8102b717f8213b/out/vs/agent/remoteExtensionHostProcess.js:732:936)
	at Function._callActivate (/home/david/.vscode-remote/bin/daf71423252a707b8e396e8afa8102b717f8213b/out/vs/agent/remoteExtensionHostProcess.js:732:625)
	at Promise.all.then.e (/home/david/.vscode-remote/bin/daf71423252a707b8e396e8afa8102b717f8213b/out/vs/agent/remoteExtensionHostProcess.js:731:635)
	at process._tickCallback (internal/process/next_tick.js:68:7)

When I set go.goroot:

"go.goroot": "/home/linuxbrew/.linuxbrew/Cellar/go/1.12.4/libexec",
"go.tooslEnvVars": { "GO111MODULE": "on" }

Things work a little better, but I have other issues with the debugger (#2505).

I have searched the code and found this hardcoded /usr/local/go/bin/go path. Would it be possible to have an exec.LookPath equivalent ?

Note also that linuxbrew installs it's dependencies through symlinks, so that IMHO symlinks should be followed.

I am not sure what the $PATH is in the WSL based extension host, but my .profile does not seem to be parsed to allow modifying the PATH. Editing /etc/environment does not fix the problem either.

[ramya-rao-a]

Apologies for the late reply @davidovich

@sandy081 When looking at the PATH env variable to find a directory where the go executable can be found I am using the below

const envPath = process.env['PATH'] || (process.platform === 'win32' ? process.env['Path'] : null);

Is it possible that in case of Remote-WSL, this platform check results in me not getting the PATH value at all?

[ramya-rao-a]

@davidovich Does your fix in #2505 (comment) help with the issue here as well?

[aaronjheng]

I met the similar problem with Remote-SSH. VM restart can fix this. What I think is that when vscode-server starts up, go binary is not in the PATH. Even you add it to PATH later, vscode-server's process holds the original PATH, so the extension can't find the go binary. But this is only my speculation.

[davidovich]

Will try to reproduce, but my access to a Windows machine will only be next Tuesday, as it is a holiday on Monday here in Canada. Le sam. 29 juin 2019 à 09:08, Aaron Jheng <notifications@github.com> a écrit :

…

I met the similar problem with Remote-SSH. VM restart can fix this. What I think is that when vscode-server starts up, go binary is not in the PATH. Even you add it to PATH later, vscode-server's process holds the original PATH, so the extension can't find the go binary. But this is only my speculation. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2504?email_source=notifications&email_token=AAK7U4WEE5PS46RFVV33X43P45NGBA5CNFSM4HLUF2LKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODY3YPUA#issuecomment-506955728>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAK7U4S7FEYW5YGRXUTNERLP45NGBANCNFSM4HLUF2LA> .

[sandy081]

@ramya-rao-a Depends on who is setting these variables. If these variables are set by the platform or node, then they should be available.

[ramya-rao-a]

@davidovich Please try the latest version of the Go extension (0.11.1) where the warning on not able to find the Go binary now includes the PATH that was searched. That should give some insights on what is happening

[davidovich]

I removed the go.goroot setting, and I am not able to reproduce, I think the latest version of the remote extension has a fix. Note that I have a greeting Salut David in my ~/.profile, and I see this greeting when the exension is launched:

[2019-07-03 15:49:21.532] Launching C:\WINDOWS\System32\wsl.exe bash -c "./scripts/wslServer.sh c7d83e57cd18f18026a8162d042843bda1bcf21f stable .vscode-server  " in c:\Users\dgenest\.vscode\extensions\ms-vscode-remote.remote-wsl-0.38.0
[2019-07-03 15:49:21.830] Updating server...
[2019-07-03 15:49:21.830] Starting server in /bin/bash...
[2019-07-03 15:49:27.535] Salut David # <-- this proves that ~/.profile is sourced now
[2019-07-03 15:49:30.538] Remote configuration data at /home/david/.vscode-server

I think we can close as it seems fixed.