New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use WSL go environment for tools #926

Open
srfrog opened this Issue Apr 14, 2017 · 39 comments

Comments

Projects
None yet
@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

This comment has been minimized.

Member

ramya-rao-a commented Apr 14, 2017

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

@srfrog

This comment has been minimized.

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

This comment has been minimized.

Member

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

@tylerb

This comment has been minimized.

Contributor

tylerb 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

This comment has been minimized.

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

This comment has been minimized.

Member

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

This comment has been minimized.

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

This comment has been minimized.

Member

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

This comment has been minimized.

Member

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

This comment has been minimized.

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

This comment has been minimized.

tiagommferreira commented May 1, 2017

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

@postgrep

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

radu-matei commented Sep 17, 2017

@ramya-rao-a

This comment has been minimized.

Member

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

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

radu-matei commented Mar 29, 2018

Any news on this?
Thanks!

@Benjiiim

This comment has been minimized.

Member

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

This comment has been minimized.

eug48 commented Jun 7, 2018

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

@xcdr

This comment has been minimized.

xcdr commented Jun 14, 2018

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

@mhamrah

This comment has been minimized.

mhamrah commented Aug 3, 2018

+1

1 similar comment
@mrpoundsign

This comment has been minimized.

mrpoundsign commented Aug 3, 2018

+1

@RobHumphris

This comment has been minimized.

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

This comment has been minimized.

tscott-au commented Aug 15, 2018

+1

2 similar comments
@raphaelvalerio

This comment has been minimized.

raphaelvalerio commented Aug 25, 2018

+1

@BloodyStupidViktor

This comment has been minimized.

BloodyStupidViktor commented Sep 2, 2018

+1

@JeffDeCola

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

dsci commented Sep 13, 2018

+1

@relston

This comment has been minimized.

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

This comment has been minimized.

lsh246 commented Oct 17, 2018

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

@xcdr

This comment has been minimized.

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

This comment has been minimized.

nkhine commented Oct 29, 2018

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

@shayne

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

redblue9771 commented Nov 16, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment