Skip to content
This repository has been archived by the owner. It is now read-only.

Use WSL go environment for tools #926

Closed
srfrog opened this issue Apr 14, 2017 · 48 comments
Closed

Use WSL go environment for tools #926

srfrog opened this issue Apr 14, 2017 · 48 comments

Comments

@srfrog
Copy link

@srfrog srfrog commented Apr 14, 2017

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
Copy link
Member

@ramya-rao-a ramya-rao-a commented Apr 14, 2017

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

@srfrog
Copy link
Author

@srfrog srfrog commented Apr 15, 2017

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
Copy link
Member

@ramya-rao-a ramya-rao-a commented Apr 15, 2017

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
Copy link
Contributor

@tylerstillwater tylerstillwater commented Apr 15, 2017

.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
Copy link
Author

@srfrog srfrog commented Apr 15, 2017

@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
Copy link
Member

@ramya-rao-a ramya-rao-a commented Apr 15, 2017

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 using gorename` 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
Copy link
Author

@srfrog srfrog commented Apr 16, 2017

@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 😞

@ramya-rao-a
Copy link
Member

@ramya-rao-a ramya-rao-a commented Apr 16, 2017

@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
Copy link
Member

@Tyriar Tyriar commented Apr 17, 2017

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)
@ioblank
Copy link

@ioblank ioblank commented Apr 26, 2017

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
Copy link

@tiagommferreira tiagommferreira commented May 1, 2017

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

@postgrep
Copy link

@postgrep postgrep commented May 25, 2017

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.
microsoft/vscode#22663

I would prefer a global option in the editor itself.

@gdrte
Copy link

@gdrte gdrte commented Jun 16, 2017

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

@radu-matei
Copy link
Member

@radu-matei radu-matei commented Sep 17, 2017

@ramya-rao-a
Copy link
Member

@ramya-rao-a ramya-rao-a commented Sep 21, 2017

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
Copy link

@lambrospetrou lambrospetrou commented Oct 16, 2017

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
Copy link
Member

@radu-matei radu-matei commented Oct 17, 2017

@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
Copy link

@lambrospetrou lambrospetrou commented Oct 17, 2017

@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
Copy link
Member

@radu-matei radu-matei commented Mar 29, 2018

Any news on this?
Thanks!

@Benjiiim
Copy link
Member

@Benjiiim Benjiiim commented May 1, 2018

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
Copy link

@eug48 eug48 commented Jun 7, 2018

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

@xcdr
Copy link

@xcdr xcdr commented Jun 14, 2018

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

@mhamrah
Copy link

@mhamrah mhamrah commented Aug 3, 2018

+1

1 similar comment
@mrpoundsign
Copy link

@mrpoundsign mrpoundsign commented Aug 3, 2018

+1

@RobHumphris
Copy link

@RobHumphris RobHumphris commented Aug 7, 2018

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
Copy link

@tscott-au tscott-au commented Aug 15, 2018

+1

2 similar comments
@raphaelvalerio
Copy link

@raphaelvalerio raphaelvalerio commented Aug 25, 2018

+1

@BloodyStupidViktor
Copy link

@BloodyStupidViktor BloodyStupidViktor commented Sep 2, 2018

+1

@JeffDeCola
Copy link

@JeffDeCola JeffDeCola commented Sep 4, 2018

+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
Copy link

@benc-uk benc-uk commented Sep 10, 2018

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
Copy link

@dsci dsci commented Sep 13, 2018

+1

@relston
Copy link

@relston relston commented Sep 17, 2018

+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
Copy link

@lsh246 lsh246 commented Oct 17, 2018

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

@xcdr
Copy link

@xcdr xcdr commented Oct 29, 2018

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
Copy link

@nkhine nkhine commented Oct 29, 2018

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

@shayne
Copy link

@shayne shayne commented Oct 29, 2018

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/

@napalm684
Copy link

@napalm684 napalm684 commented Oct 31, 2018

@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?

@napalm684
Copy link

@napalm684 napalm684 commented Nov 1, 2018

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
Copy link

@redblue9771 redblue9771 commented Nov 16, 2018

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

@nicowernli
Copy link

@nicowernli nicowernli commented Dec 1, 2018

@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
Copy link

@nicowernli nicowernli commented Dec 1, 2018

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
Copy link

@jdan jdan commented Dec 19, 2018

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)

image

@nicowernli
Copy link

@nicowernli nicowernli commented Dec 19, 2018

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
Copy link
Member

@ramya-rao-a ramya-rao-a commented May 3, 2019

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
Copy link

@shayne shayne commented May 3, 2019

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

@redblue9771
Copy link

@redblue9771 redblue9771 commented May 3, 2019

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
Copy link

@ghost ghost commented May 22, 2019

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

@ramya-rao-a
Copy link
Member

@ramya-rao-a ramya-rao-a commented Jul 7, 2019

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

@ramya-rao-a ramya-rao-a closed this Jul 7, 2019
@microsoft microsoft locked as resolved and limited conversation to collaborators Jul 7, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet