Use WSL go environment for tools

[srfrog]

I would like to have my environment set in WSL (bash.exe) and not in Windows, can vscode-go exec bash.exe before running the tools (golint, goreturns, etc) ?

I have the following settings but doesn't appear to work:

    "terminal.integrated.shell.windows": "C:\\WINDOWS\\sysnative\\bash.exe",
    "terminal.external.windowsExec": "C:\\WINDOWS\\sysnative\\bash.exe",
    "go.goroot": "/usr/local/go"

vscode alerts with:

Cannot find \usr\local\go\bin\go.exe

[ramya-rao-a]

Can you try pointing your PATH to /usr/local/go/bin/ and restart VS Code?

[srfrog]

Can you be more specific? Set PATH where, WSL or Windows? I have /usr/local/go/bin in ~/.bashrc and ~/.profile, no luck.

From cmd.exe when I run bash -c 'echo $PATH', I don't see my /usr/local/go/bin in PATH. So perhaps bash.exe ignores .bashrc and .profile initially. Any ideas?

[ramya-rao-a]

Taking a step back, you are on Windows and you have set the go.goroot to be /usr/local/go which doesn't look like a valid path in Windows.

go.goroot should be point to the path where you have the Go executable.

Next, about your ask

I would like to have my environment set in WSL (bash.exe) and not in Windows

Sorry, but I don't understand what exactly you are trying to do here. Are you saying that you want to use bash in the integrated terminal?

cc @tylerb for terminal related queries

[tylerstillwater]

.bashrc should be executed for non interactive shells, which would mean your path should be set correctly. If not, then you need to debug if/why .bashrc is not being executed. I don't know anything about bash in windows, so I'd recommend googling around a bit.

[srfrog]

@ramya-rao-a I thought that by changing terminal.integrated.shell.windows and terminal.external.windowsExec to use bash.exe (Windows Subsystem for Linux) it would allow vscode-go to use the go tools in the lxss environment. This feature would be ideal for people that are leaving macOS for Windows+WSL.

Perhaps this is a setting in electron/nodejs. I'll do some more digging.

[ramya-rao-a]

Oh sorry @tylerb, I meant to cc @Tyriar (our resident terminal and linux expert), did a premature auto-complete and your name got entered :)

@srfrog ah! I think I am following what you are trying to do a little better. You are referring to the usage of go tools (like formatting using gofmt/goimports/goreturns, renaming usinggorename` etc) and want them to run in WSL instead of Windows.

Currently, we use simple child_process in the Go extension to run the Go tools. How WSL plays into this, I don't know.

@Tyriar thoughts?

[srfrog]

@ramya-rao-a vscode-go is using child_process.execFile() which is why the shell settings aren't used. Additionally, path.getGoRuntimePath() is hard-coded to C:\Go\bin\go.exe on windows, so it will never detect Go in WSL. I will play around with these, most likely a new setting for WSL is needed that makes use of child_process.exec() and checks for the setting value in getGoRuntimePath().

e.g., go.useWSL = true || false

The actual command string might look like:

cmd.exe /d /s /c bash.exe -ic '{command}'

Unfortunately, NodeJS is hard-coded to use cmd.exe /d /s /c {command} on windows :disappointed:

[ramya-rao-a]

@srfrog

Regarding the go runtime path

path.getGoRuntimePath() first tries to find the go binary/executable as per the path in go.goroot first and then the PATH. If not found, then it tries C:\Go\bin\go.exe on windows and /usr/local/go/bin/go on other platforms.

In your case, looks like it says "\usr\local\go\bin\go.exe" which is weird to me because it is looking for an "exe" in a non Windows like path. I'd suggest to get a local environment of the Go extension set up and debug to see how exactly are you ending up with this scenario. Instructions: https://github.com/Microsoft/vscode-go/wiki/Building,-Debugging-and-Sideloading-the-extension-in-Visual-Studio-Code

Regarding shell usage

So are you saying that if we use child_process.exec and pass the shell option, you should be able to get the expected behavior?

[Tyriar]

This was brought up for the git support recently, not sure what the result of that conversation was yet.

The actual command string might look like:

cmd.exe /d /s /c bash.exe -ic '{command}'

Does adding bash.exe -ic work? Seems like a pretty good solution to me, if this is the direction the Go extension goes, @ramya-rao-a will probably need to make sure all paths are mapped to and from the /mnt/c/... and C:\... formats correctly.

In your case, looks like it says "\usr\local\go\bin\go.exe" which is weird to me because it is looking for an "exe" in a non Windows like path.

What's probably happening here is it's assuming go.goroot is a standard Windows style path and transforming it so:

/usr/local/go
\usr\local\go
\usr\local\go\bin\go.exe (look in the bin\ for go.exe)

[dibiasefrn]

Does adding bash.exe -ic work? Seems like a pretty good solution to me, if this is the direction the Go extension goes, @ramya-rao-a will probably need to make sure all paths are mapped to and from the /mnt/c/... and C:\... formats correctly.

I've done just that in my (somewhat messy) fork and, bare a few remaining bugs, it works! But it's considerably slower than native tools. :( Any ideas for speeding it up?

In case you're interested in trying it out, here's an example of what you need to add to the vscode settings.json:

"go.useWsl": true,
"go.goroot": "/mnt/c/local/go",
"go.gopath": "/mnt/c/go",

[tiagommferreira]

Any updates on this? WSL integration would be really useful.

[postgrep]

I think an option to choose to either use the Windows environment or the WSL environment should be provided direcly by the editor, not by each plugin.

Other language plugins for VScode for Windows have this issue too. https://github.com/DonJayamanne/pythonVSCode/issues/534

I think the following issue in vscode itself relates to this one. https://github.com/Microsoft/vscode/issues/22663

I would prefer a global option in the editor itself.

[gdrte]

Integration with WSL is highly preferable for users like me, who just moved from Mac OS X to Windows X :).

[radu-matei]

I think the C++ tools for VS Code on Windows make use of WSL (I haven't used yet, this is only based on their docs).

It would be great to have the same for Go.

[ramya-rao-a]

Hello all,

There is no update as of yet. There is some talks to better support WSL in general in VS Code. When these talks solidify a bit, I'll see how we can bring over such support to the Go extension.

[lambrospetrou]

I would really love for this to go forward too. The only way now to work with WSL is to run the editor locally in WSL and display it in Windows using X-Server. But this does not work with VSCode though and I fall back to Sublime.

An option to use WSL entirely in the editor would be amazing.

[radu-matei]

@lambrospetrou you could use VS Code on Windows and use Bash as the integrated terminal, executing the go commands against Linux.

Not the best experience, but gets the job done.

[lambrospetrou]

@radu-matei I know about that but the whole benefit of having a plugin for a language is to provide editor assistance (autocomplete, suggestions, auto formatting on save, highlighting errors, etc.). If I was just using it as a notepad and then run commands through terminal, I could just use the normal terminal, not VSCode's.

[radu-matei]

Any news on this? Thanks!

[Benjiiim]

It seems that VS Code has a debugging option "useWSL" which aims to acheive that. Cf https://blogs.msdn.microsoft.com/commandline/2017/10/27/running-node-js-on-wsl-from-visual-studio-code/ Wouldn't it make sense to use this setting for Go as well?

[eug48]

WSL could enable use of Sourcegraph's Language Server on Windows, potentially improving editor latency?

[xcdr]

Support for WSL is important to me, any complete solution is desirable.

[mhamrah]

+1

[mrpoundsign]

+1

[RobHumphris]

Another please please please vote from me. I am writing go code on my Windows machine that runs a number Linux executable binaries, so the debugger needs to run in the context of the WSL for me to inspect the command and ProcessState values.

[tscott-au]

+1

[raphaelvalerio]

+1

[BloodyStupidViktor]

+1

[JeffDeCola]

+1

On a side note, this can get confusing on where everything lives since we have two operating systems. So I made a pic on how everything currently fits together. Hope this helps.

[benc-uk]

Sorry to be another +1'er but this is a problem that plagues VSCode. Using Git, Node, Python and Golang requires me to have the them all installed twice, once in WSL and once in Windows. It's very messy, very confusing & requires multiple configurations that can get out of sync

[dsci]

+1

[relston]

+1 From someone who migrated from MacOS to Win10 specifically because WSL is now an option this setup is kind of a bummer. Is there a thread where we can speak to the more generalized option that was suggested above by @postgrep? That would be ideal. Any update would be appreciated, thanks!

[lsh246]

Another +1. Moving from MacOS to Win10 building Linux binaries and wish I could debug seamlessly in VSCode.

[xcdr]

This is also important for me, I cannot switch from MacOS to WIndows 10 without this feature.

There a lot of time has passed and we still do not know when it will work.

[nkhine]

+1, I have the same, I am developing functions for serverless in golang on windows10

[shayne]

While having this issue resolved within VSCode would be nice, I've found that using VSCode installed under WSL, using X410 (Windows Store) as the X11 server, is incredibly seamless and solved my immediate needs.

Installing VSCode in WSL Ubuntu is as easy as downloading the .deb package from the VSCode website. Running sudo apt install <deb-file>, then creating a shortcut that launches VSCode from within WSL utilizing the X410 (which enables GUI Linux apps on Windows, i.e. WSL GUI apps).

https://token2shell.com/howto/x410/creating-shortcut-for-wsl-gui-desktop/

From there you setup Ubuntu under WSL as you would a Linux dev environment. Fonts can be copied over from Windows to ~/.local/share/fonts and are made available to the Linux apps.

For better looking UI take a look at the X410 how-to below: https://token2shell.com/howto/x410/setting-the-theme-for-linux-gui-apps-windowed-apps-mode/

And halfway down in this how-to they show how to install Adapta theme, which I thought looked good: https://token2shell.com/howto/x410/customizing-xfce-desktop-for-ubuntu-wsl/

[NapalmCodes]

@shayne I pursued this today looks ok but I'm curious how stable given guis aren't officially supported by WSL. What has your stability experience been like?

[NapalmCodes]

Also (sorry for double post) delve for debugging doesn't seem to work this way. Any special config needed?

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Debug",
            "type": "go",
            "request": "launch",
            "mode": "auto",
            "program": "${fileDirname}",
            "env": {},
            "args": [],
            "showLog": true
        }
    ]
}

[redblue9771]

Have you solved this problem? I can't get any relevant news.

[nicowernli]

@srfrog

Regarding the go runtime path

path.getGoRuntimePath() first tries to find the go binary/executable as per the path in go.goroot first and then the PATH. If not found, then it tries C:\Go\bin\go.exe on windows and /usr/local/go/bin/go on other platforms. ...

What about returning wsl.exe /usr/local/go/bin/go instead of C:\Go\bin\go.exe if an option like useWSL is enabled?

EDIT: Maybe using first wsl.exe (resolved go.goroot) and then wsl.exe /usr/local/go/bin/go

[nicowernli]

I've made a test to see if it was possible to run tests from WSL and everything worked fine.

bash.exe -c 'cd PATH_TO_GO_MODULE && GOOS=linux GO111MODULE=on /usr/local/go/bin/go test -run ^TestWSL$'

Running the bash.exe won't load the environment variables configured in your wsl linux, so you need to set every thing again (this could be loaded from the go.testEnvVars)

[jdan]

Just chiming in here as I've gotten this working with my ocaml tools (VSCode running in windows, with plugins that make calls into Linux)

You'll want to make some aliases to your linux bin's with the following tool: https://github.com/leongrdic/wsl-alias

Here's the end result for me (https://twitter.com/jdan/status/1031290277242306566)

[nicowernli]

After installing the wsl-alias I'm able to run linux go commands from powershell. The proble is that the extension will add the .exe to the executable if detectes that you are running it on windows.

Would be nice to have a go.executable config to override that behaviour.

[ramya-rao-a]

Hello everyone, we finally have an update here!

Checkout the below tweets from the official VS Code twitter handle: https://twitter.com/code/status/1124057230624665620 https://twitter.com/code/status/1124016109076799488

And the official blog post on Remote Development with VS Code

Please try out the above extensions and log new issues if any of the features of the Go extension doesn't work as expected.

Please note that you need to have the latest Insiders for the above to work

[shayne]

@ramya-rao-a incredible! Can't wait to try it out. Thank everyone for me, will ya

[redblue9771]

I am so happy to hear that VS Code officially supports the remote development mode, which includes ssh mode, docker mode and wsl mode. Although not perfect, the official saw our needs. From Chinese developers

[ghost]

I tried the links above but still cant add breakpoints for my go code

[ramya-rao-a]

Closing this issue as we now have Remote Development with VS Code

If you see any problems working with the above, please log new issues