Find and utilise WSL Python Environments about vscode-python

[brettcannon]

I just wanted to let everyone know that we are in contact with the VS Code team and they are exploring support for WSL (as listed in their January iteration plan). We are working with them to make sure the extension can work with whatever solution they come up with (but the VS Code team already reached out to us about their work so they are making sure we will be covered 😃 ).

[brettcannon]

As a reminder, to help bump up the priority for this please leave a 👍 reaction on the top comment. Individual comments requesting priority are honestly just a distraction to us and anyone else providing workarounds until we are able to build in official support.

And just to be clear, our priority list of future work is based on what people say in the survey we randomly pop up for people and the feature requests with the most 👍 reactions. IOW this feature can't really get much higher on our priority list (we just have not started on it because of the experimental debugger and language server work is taking all of our time ATM). 😉

[brettcannon]

As a rule we don't give updates because we don't want the pitchforks if we predict wrong 😉 Just know that we are well aware of the desire for this support and that we personally want it to. We are also working towards landing our new debugger and language server which are not exactly small projects. Once those are two are out of the way, the top 5 projects goes down to 3 and this is on that list. 😄

[brettcannon]

Not Python-specific, but if you are willing to spend 30 minutes with the VS Code team interviewing you about your use of WSL and in return get to find out what they have planned, please fill out this form.

[jswh]

Hi!
I have made some change to wslgit to support python (or maybe other commands).

The project wslgit makes a dummy exe that trying to receive the arguments and translating all paths from windows type to unix type, and reform these arguments to the real command in wsl .

It was made for git only. I changed it to use the file stem name as the real command. It works!

I did not test it in complex usage, there should be more work.

test

[DonJayamanne]

From @postgrep on May 25, 2017 21:19

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

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.

[JohnBloom]

Is there anywhere public that the global solution is being tracked? This is a really important feature and it would nice to have a thread to check and see what direction the solution is going.

[Voronoff]

I've written a Gist for getting Python code completion, navigation, debugging and linting to work with WSL until there is an out of the box solution:

https://gist.github.com/Voronoff/059c50f9fd354386c305c55af1f3a61f

[TiemenSch]

I'm currently maintaining a Python install on both WSL and Windows to workaround this exact issue. Then at least I've got some IntelliSense for the packages available on Windows. Far from ideal, though.

[burhan]

Would it be too much to ask to include pyenv support as well? That way you don't end up relying on the base system Python in WSL for all your work.

[TiemenSch]

This extension screams at me until I select a Windows-based (Installed) interpreter. If I install it, set it as my interpreter, and I have bash (WSL) set as my terminal shell, the command successfully sends to the terminal, but fails to execute the pylint installer command. If the extension simply followed the rules of using the system-wide setting for terminal shell and using the pythonPath set in the extension settings, all would be well... Why does the extension rely so heavily on the local (Windows) installation of Python?
+1 for adding WSL support to this (and all) VSCode extensions

Well, it relies on Windows because you run VSCode on Windows. It's rather strange for any installed program to think it half-runs on another OS out of the box by default. Even your WSL terminal is launched as a Windows application (that in turn mimics a lot of Linux stuff behind the scenes). I understand your "so close!" feelings though ;).

The most "native" experience you can get with WSL is the earlier mentioned VcXsrv workaround, where VSCode is launched from WSL.

Challenges

As far as I know, the two major challenges are:

1. Bi-directional path translation:
   1. WSL does not like C:\something (both the drive mount part and the backslashes).
   2. In turn, Windows drops the ball as soon as it sees /mnt/c and sometimes (although less) on forward slashes.
2. Communication with any GUI application part.
   1. This would require some form of X-server setup as a workaround, but it's questionably reliable.

Tackling the first would at least enable all terminal applications to run peacefully, which would be great. There may be WSL limitations, though, but there is no need to tackle those in this extension.

Last but not least, there should be a non-confusing way to set this up. Merely by reading this thread you come across a lot of misconceptions on what WSL is and how "easy" this should work.

In short

I think the desire for this feature is more than clear. No need to provide any use-cases in comments anymore.

The fact that it isn't implemented (yet!) proves that the community has difficulty with getting it to work properly or knowing where to start.

Contributions towards a solution

In my opinion, the best ways to contribute code would be:

1. Recapping the WSL workarounds in a clear and concise document to include in the docs. We could link to this document in the issue's starting comment to point anyone looking for workarounds in the right direction.
2. Tackling the first challenge in a (partial) PR, so we can start working towards a solution. I sure hope Michael @micmelesse is able to find time for this!

I get the feeling that if anyone with some JS knowledge would lay the groundwork, that we can all move from there step by step.

Or just a PR where implementation can be discussed instead of desire for features :)?

[nikhilweee]

What's the current progress on this issue?
Also, in the meanwhile, please disable the redirect to python.org when I click close. It's really annoying!

[brettcannon]

@TaipanRex python.pythonPath is expected to specify an executable, not something to take an argument (although we are thinking of allowing the specification of interpreter args which might solve this).

[mattz0rt]

Just wanted to mention that I've tried a few of the options here but they all seem to have their own issues when attempting to do anything beyond running tests and linting (e.g. debugging). Until MS releases a more robust integration I'd recommend just running vscode within WSL via a X Windows server (currently using VcXsrv). You can then just shortcut it via C:\Windows\System32\cmd.exe /c bash -c "DISPLAY=:0 code"

[sgharms]

MS releases a more robust integration

That's really the ❤️ of this whole thing since on Nov 27, 2017.

[rcarmo]

I'm currently maintaining a Python install on both WSL and Windows to workaround this exact issue. Then at least I've got some IntelliSense for the packages available on Windows. Far from ideal, though.

Ditto. I keep going up against stuff like this.

[dev542]

+1

[Biohacking-zhangyp]

Install extension Code Runner. Add config into your user setting like this:

Thanks for this. I use Code Runner but hadn't thought to use it to translate the Windows paths to Unix paths.

Is there a way to get it working with my WSL venv? It tries to use the env that I set in VS Code, which obviously has to be Windows.

Just add ("code-runner.terminalRoot": "/mnt/") into your user setting. When you run code, it will replace Windows paths prefix "D:" or "C:" with "/mnt/".
And it work with your WSL venv, when you add this:

"terminal.integrated.shell.windows":"C:/Windows/System32/bash.exe",
"code-runner.runInTerminal":true

It work with your windows venv, when you add this:
"code-runner.runInTerminal":false
It work with your remote server venv, when you add this:

"terminal.integrated.shell.windows":` `"C:/Windows/System32/bash.exe",
"code-runner.runInTerminal":true

and config your SSH-FS like this:

"sshfs.configs": [
{
"label": "label",
 "root": "/",
"host": "host",
"port": port,
"username": "name",
"password": "password"
"name": "name"
}]

and login your remoter server account in vscode terminal over ssh

[mattalhonte]

That'd be fantastic. If I could access my conda envs in WSL from VSCode, that'd be the best of both worlds.

[lego-sharat]

Does the coderunner solution provide suggestions while writing autocomplete or it simply translates path at run time?

[caylorme]

This extension screams at me until I select a Windows-based (Installed) interpreter. If I install it, set it as my interpreter, and I have bash (WSL) set as my terminal shell, the command successfully sends to the terminal, but fails to execute the pylint installer command. If the extension simply followed the rules of using the system-wide setting for terminal shell and using the pythonPath set in the extension settings, all would be well... Why does the extension rely so heavily on the local (Windows) installation of Python?
+1 for adding WSL support to this (and all) VSCode extensions

[ncoghlan]

Similar to @TiemenSch, I'm currently relying on the dual WSL/Windows Python installation approach, which actually works pretty well for most purposes (in particular, it's sufficient to get "pylint -E" and other static checks running). (I don't use any of the test execution helpers in VS Code, though - I have a separate WSL console window for that. That isn't a burden for me personally, since I never used those anyway)

That means that the discrepancy now mainly shows up when the linter is checking usage of low level operating system API modules - since the code I'm working on uses a lot of the lower level *nix specific APIs in Python, running the linter on the Windows-side Python interpreter complains about missing imports and attributes.

[TiemenSch]

Not sure if this page is entirely up-to-date, but may prove a useful read:
https://docs.microsoft.com/en-us/windows/wsl/interop

Sharing that specific path variable between Windows and WSL could prove useful, right?

I'm not very familiar with the inner workings of the extension regarding environment detection and usage (any pointers?). Still, adding a new block of "also detecting WSL envs on Windows" seems reasonably doable.

I would imagine there needs to be a layer for "getting into WSL commands", executing what you use for VS Code on Linux already and "returning stuff to Windows commands".

Can anyone point me to the related files in this extension? If there already exists any documentation on how the current environment selector is populated, that would be really useful, too!

[TiemenSch]

Is this of any help: https://blogs.msdn.microsoft.com/commandline/2017/10/27/running-node-js-on-wsl-from-visual-studio-code/
?

Edit: nope, wait, that is accessing Node on WSL itself. Jumped to conclusions.

Or the useWSL property should have a more universal use. Any chance that translates paths for you?

At the very least, the work they did for accessing node on WSL correctly may also translate (partly) to our case accessing Python.

[TaipanRex]

@TiemenSch paths are not a problem, from the article you linked you can see they are using bash -i -c "npm rebuild", we want to do the same, run bash with -c and not /d switches, which seems to be a Node issue.
Edit: If I can find where the useWSL is implemented, we might find something that we can use, but a search on Github revealed nothing. I'll have to clone the whole repo and do a grep.

[TiemenSch]

As you were interested in the useWSL flag, I tried looking around for its introduction. Here are some pages I found:

Pull request for VS Code node debugging in WSL: microsoft/vscode-node-debug#158

Updates and usage of remote debugging for node:
https://code.visualstudio.com/updates/v1_17#_first-steps-towards-wsl-support
https://code.visualstudio.com/docs/nodejs/nodejs-debugging#_remote-debugging

Launch .json useWSL only on Windows: microsoft/vscode#42723

[jerivas]

That's correct. For what is worth, I've been using the method you described extensively and it works just fine.

…

On Thu, May 10, 2018, 6:10 PM Omar ***@***.***> wrote: Fairly new to using Visual Studio Code, if I understand this correctly the best work around right now is to just install Python until the useWSL is implemented in the Python plugin? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#67 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACR8Ps5jV-Ah2NgHfG12iJ1xaSr6or7_ks5txNb1gaJpZM4QcdzU> .

[Biohacking-zhangyp]

Install extension Code Runner. Add config into your user setting like this:

"terminal.integrated.shell.windows": "C:/Windows/System32/bash.exe",
    "code-runner.runInTerminal":true,
    "code-runner.fileDirectoryAsCwd": true,
   `"code-runner.ignoreSelection": true,
   `"code-runner.terminalRoot": "/mnt/",
    "code-runner.saveFileBeforeRun": true,
    "files.eol": "\n",
    "code-runner.executorMap": { "python": "python3 -u"}

Install SSH-FS, you even can run your code on remote server. Just config like this:

   "sshfs.configs": [
        {
            "label": "label",
            "root": "/",
            "host": "host",
           "port": port,
           "username": "name",
           "password": "password"
           "name": "name"
        }]

[Stavrosnco]

Does the coderunner solution provide suggestions while writing autocomplete or it simply translates path at run time?

Unless I have mine configured wrong it translates the path at run time and does not have an effect on autocomplete.

[comfortablynick]

Just wanted to mention that I've tried a few of the options here but they all seem to have their own issues when attempting to do anything beyond running tests and linting (e.g. debugging). Until MS releases a more robust integration I'd recommend just running vscode within WSL via a X Windows server (currently using VcXsrv). You can then just shortcut it via C:\Windows\System32\cmd.exe /c bash -c "DISPLAY=:0 code"

Thanks for this idea. I did install this, but the fuzzy text/graphics really bug me. It's not too bad, but definitely not as crisp as the native Windows app.

Right now, I'm just having to install duplicate packages on my Windows venv and am using the Code Runner extension to run everything in my Linux venv. Not ideal, but at least everything works. It will be great when VS Code can directly use the Linux Python interpreter.

[bondib]

+1

[rcarmo]

I just added a reference to this from another issue since it impacts the same base functionality (i.e., picking up Python versions from the context the developer is working in), and picking up the right Python from inside WSL also needs to take into account pyenv.

(Also, I just remembered to mention that debugging and linting needs to be taken into account, since I just installed the extension again and it tried to add pylint to my system Python, which is... interesting if you take WSL and pyenv into account).

[arijoon]

@TaipanRex I have done a grep on vscode repo for "useWSL" but found no matches, the only match for WSL is on

resources/win32/bin/code.sh:    # If running under WSL don't pass cli.js to Electron as environment vars
resources/win32/bin/code.sh:    # cannot be transferred from WSL to Windows

and the shells entry:

src/vs/workbench/parts/terminal/electron-browser/terminalService.ts:                    'WSL Bash': [`${system32Path}\\bash.exe`],

I have not done any extension development on vscode so wouldn't really know how it hooks in together, if there is somewhere else to look for this let me know and I can do some digging.

The version checked above is: 1.16.0-10366-gae223635fe (result of running git describe)

[TaipanRex]

@Voronoff thats a clever solution.

You might be able to shorten those .bat files even further by using wslpath to do path translation for you, which was included in release 17046. I have gist on how i use it with Ranger to open Windows files.

[d3r3kk]

@jayspang:

Am I reading this correctly that Python debugging with VSCode is completely broken on Windows?

No. Debugging works on Windows just fine. Perhaps it's confusing, but I'm not 100% sure where you got that idea as this github issue is specific to WSL.

I'd be happy to have this issue resolved and have everything working in WSL

Stay tuned... no ETA but it's definitely being discussed today.

I'd be happy if the Python Debug Console just used cmd.exe

Then you are in luck. That is definitely supported well used today!

[comfortablynick]

Install extension Code Runner. Add config into your user setting like this:

Thanks for this. I use Code Runner but hadn't thought to use it to translate the Windows paths to Unix paths.

Is there a way to get it working with my WSL venv? It tries to use the env that I set in VS Code, which obviously has to be Windows.

[TiemenSch]

I think you could start by locating where the OS specific code (if platform==xxx) resides and where the path-translations happen. I did some basic searches through the files some time ago, but lacked the required JS knowledge to implement something useful. To check whether code is being run from WSL, you can use a snippet similar to this one:
https://github.com/sindresorhus/is-wsl/blob/master/index.js

[DonJayamanne]

From @rogersachan on November 21, 2016 2:9

I'll close #195 since this is better worded

[DonJayamanne]

From @shanalikhan on December 14, 2016 10:59

+1 , i am using python extension in code inside ubuntu and inside virtual box :)
Would love if Bash support is provided with intellisense so i can use Bash with this extension and compile using bash libraries

[DonJayamanne]

From @M-Adoo on December 18, 2016 7:27

+1

That be nice, if i can use wsl python enviroment across some config.

like this ?

{
   "python.linting.pylintPath": "C:\\Windows\\sysnative\\bash.exe",
    "python.linting.pylintArgs": ["-c", "pylint"]
}

[DonJayamanne]

From @csholmq on January 9, 2017 15:10

Using @M-Adoo's approach, but with "terminal.integrated.shell.windows": "C:/Windows/sysnative/bash.exe" instead, debugging using "Integrated Terminal/Console" launches WSL successfully. But then it tries calling

$ cd null ; env PYTHONIOENCODING=UTF-8 python C:\Users\sholmq\.vscode-insiders\extensions\donjayaman
ne.python-0.5.5\pythonFiles\PythonTools\visualstudio_py_launcher.py null 60475 34806ad9-833a-4524-8cd6-18ca4aa74f14 WaitOnAbnormalExit,WaitOnNormalExit c
:\Users\sholmq\Desktop\pycflow2dot\pycflow2dot.py

to try and launch visualstudio_py_launcher.py. The problem is that on WSL, the C:/ root is at /mnt/c/ instead.

Any way to change this?

@DonJayamanne Perhaps with a setting python.extensionPath, or better yet, python.wslEnable to convert paths from C:/ to `/mnt/c/?

[DonJayamanne]

From @tmcdonnell87 on January 25, 2017 5:12

+1

[DonJayamanne]

From @dalyIsaac on February 9, 2017 2:32

+1

[DonJayamanne]

From @rogersachan on February 9, 2017 2:44

Please see microsoft/vscode-cpptools#85 (comment)

It appears a API will be made available for WSL/Bash for Windows.

[DonJayamanne]

From @joel-wright on April 18, 2017 18:24

Is there any update on this or the other Bash on Windows 10 issues?

[DonJayamanne]

Unfortunately nothing yet.

[DonJayamanne]

From @overshard on May 17, 2017 23:4

I'm still looking for this too, it appears to be a matter pythonVSCode can't be told if it's executing stuff on windows or on WSL. We just need a way to have it use WSL pathing /mnt/c/Users/"USERNAME"/.vscode/extensions/... instead of the windows path and we could atleast get projects running through the integrated terminal functionality. Pretty much what @csholmq says above.

[DonJayamanne]

From @rjgonza on June 23, 2017 16:9

+1

[DonJayamanne]

From @hacdias on October 28, 2017 19:23

+1

[DonJayamanne]

From @trungtrinh44 on October 29, 2017 15:47

+1

[DonJayamanne]

From @brettcannon on October 30, 2017 21:46

FYI, the best way to vote for a feature is to simply use the 👍 reaction on the top message in the feature request as that helps provide a concrete number of how many people want this. +1s get lost in the noise of the feature request and end up generating email for everyone following this issue.

[sgharms]

@DonJayamanne In microsoft/vscode#39144 the direction seemed to be "let's learn what we can by supporting Win/WSL switching for NodeJS. as a one-off." I'd contend that doing that for another accessible language e.g. Python might also be helpful.

I fully agree that your desire for a global solution is preferable to every plugin writing its own switch logic, but Python might shake out even more insight than Node does.

Regardless, it seems like support for Code + WSL + Python is going to be stalled until the Real Deal Global solution is identified, correct?

[sgharms]

You're right @DonJayamanne, I mis-attributed your citation of @postgrep 's comment. I stand corrected.

…

On Mon, Nov 27, 2017 at 10:44 PM, Don Jayamanne ***@***.***> wrote: your desire for a global solution is preferable to every plugin writing its own switch logic @sgharms <https://github.com/sgharms> , not sure why you're under the impression that I'm after a global solution. I have said no such thing. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#67 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADDYxyJRFpcSalpx5PR6OdeZb6gzWTkks5s64GogaJpZM4QcdzU> .

-- Steven G. Harms PGP: E6052DAF <https://pgp.mit.edu/pks/lookup?op=get&search=0x337AF45BE6052DAF>

[DonJayamanne]

I figured.
Please be assured that this is something we will be looking into. Will keep you posted

[brettcannon]

@JohnBloom this issue is where the work will be tracked.

[brettcannon]

@nikhilweee Adding proper WSL support is probably in our top 5 features we want to see happen, but the ones taking precedence are massive and taking up all of our time at the moment. We would happily review any PRs people want to submit to help accelerate getting this in, but at the moment we just don't have the bandwidth.

As for the banner, please open a separate issue.

[nikhilweee]

@brettcannon Thanks for your reply. It feels good to hear that.

[sgharms]

@brettcannon I'll second @nikhilweee, it's good to see a status update.

For those coming across this issue I'll direct them to the build VSCode from source page and note that while I've been spooked to try to help build a new version (because I didn't want to download a huge IDE C++ toolchain), it looks like that can be avoided by using a windows-build-tools package.

[brettcannon]

@sgharms Just an FYI there is no need to build VS Code to contribute to the extension (it's all just TypeScript; see the CONTRIBUTING guide for how to get started).

[sgharms]

@brettcannon Thanks for the tip. I had (wrongly, it seems) assumed that I would need to have access to a lower level API in order to ask the OS what context (WSL/Command) I was in. If not, I'll try to find a way in!

[DonJayamanne]

@sgharms
This branch might help https://github.com/DonJayamanne/pythonVSCode/commits/wsl
I did experiment on adding supporting to WSL, but left that due to other tasks that were more urgent.

Basically, the solution (temporary) work around is:

• Run python inside a bash shell and get the output (jsut as we do today, instead we're adding the bash layer here)
• A better and longer term solution would be to stop using jedi and using stdout to communicate with a process (i.e. build a language server).

[rcarmo]

Can’t the existing Python language server be injected into WSL somehow?

…

On 21 Feb 2018, at 21:22, Don Jayamanne ***@***.*** ***@***.***>> wrote: @sgharms <https://github.com/sgharms> This branch might help https://github.com/DonJayamanne/pythonVSCode/commits/wsl <https://github.com/DonJayamanne/pythonVSCode/commits/wsl> I did experiment on adding supporting to WSL, but left that due to other tasks that were more urgent. Basically, the solution (temporary) work around is: Run python inside a bash shell and get the output (jsut as we do today, instead we're adding the bash layer here) A better and longer term solution would be to stop using jedi and using stdout to communicate with a process (i.e. build a language server). — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#67 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAX968Q5vVOglh3P6I1JjLSBVTayH2rbks5tXIkJgaJpZM4QcdzU>. <https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png> <https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png> <https://github.com/Microsoft/vscode-python> <https://github.com/DonJayamanne/pythonVSCode/commits/wsl/r/nI> <#67 (comment)>

[DonJayamanne]

Can’t the existing Python language server be injected into WSL somehow?

We don't have a language server today.

[sgharms]

These are all very helpful ideas. Thanks!

[TaipanRex]

@TiemenSch thanks for the link. There is a setting python.pythonPath to set the Python interpreter path instead of VSCode pulling it from the path variable. I tried using the WSL path to python, also tried wsl /usr/bin/python but that does not work. It seems to me that VSCode is expecting a .exe file in that path and that you cant set the python command wsl.exe python.

Would also like to look at the actual code for the extention.

[TaipanRex]

I took a look at the extension code, seems child processes are created using exec(), in pythonProcess.ts. exec() has an option to set the shell that will run the given command in the child process, so a solution might be to allow a user to set this option. This should mean you don't need to change any code related to the actual command or setting interpreter args.

There is one problem that I have not been able to figure out yet: if you set {shell: 'bash.exe'} in the exec() options, as you are running VSCode in Windows, it will try to execute the command by running /d /c command. Bash does not understand this so you get the error /bin/bash: /d: No such file or directory. The Child Process docs state the following for shell requirements:

The shell should understand the -c switch on UNIX or /d /s /c on Windows. On Windows, command line parsing should be compatible with cmd.exe.

There might be a way in Node to set how commands are run, or to fool it to think you are running Linux. I don't know how Node decides which switch to use.

A last note is that in configSettings.ts, the function isValidPythonPath uses execFileSync to check if the user-set pythonPath is correct. execFileSync() does not use a shell, so we would have to refactor the function to use execSync() instead. The same is used in src/client/debugger/Common/Utils.ts

[IBeRamen]

Fairly new to using Visual Studio Code, if I understand this correctly, the best work around right now is to just install Python until the useWSL is implemented in the Python plugin?

[TiemenSch]

I came across this one:
https://github.com/Microsoft/vscode-cpptools/blob/master/Documentation/Debugger/gdb/Windows%20Subsystem%20for%20Linux.md

Is that of any inspiration?

This part seems hopeful:

    "pipeTransport": {
        "pipeCwd": "",
        "pipeProgram": "c:\\windows\\sysnative\\bash.exe",
        "pipeArgs": ["-c"],
        "debuggerPath": "/usr/bin/gdb"

I think the bash location is C:\Windows\System32\bash.exe, but the piping looks promising.

EDIT: only just saw that @DonJayamanne already linked to the repo before.

[TiemenSch]

Perhaps nodejs' implementation is by far the most elegant I came across up until now.

https://github.com/Microsoft/vscode-node-debug/blob/master/src/node/wslSupport.ts

This is the file responsible for the magic I believe. It doesn't even mention node!

[rcarmo]

That file seems generic enough to do most of what we need, and might do with a few more tweaks around environment handling.

[TiemenSch]

That's a lot of tools you "like", confusing what the actual workaround is that you propose?

[Voronoff]

It's a guide to getting set up from scratch. Jump to the Python + WSL section using the table of contents. I use bat files along with a bash function for setting up workplace settings to use the virtual environment for the project.

[mahmoudajawad]

I've written a Gist for getting Python code completion, navigation, debugging and linting to work with WSL until there is an out of the box solution:
https://gist.github.com/Voronoff/059c50f9fd354386c305c55af1f3a61f

This seems the best approach so far. Can we pack it as plugin for vscode that creates the files automatically, @Voronoff?

[TiemenSch]

I believe the path translation is also included right in the https://github.com/Microsoft/vscode-node-debug/blob/master/src/node/wslSupport.ts I mentioned earlier.

IMHO, that approach looks cleaner and should be better to implement as it relies on the same language the extension is typed in.

However, when I went about and tried to fiddle in the vscode-python extension I hit a wall since I have no experience in TypeScript (or JavaScript for that matter) and the node and python packages are structured a bit differently. Before I knew it, I had to change configs in so many places that I was unsure if any of it would at all be executed.

Also, you have to be careful with translating paths as the extension itself is still running on Windows, but only 'talking' to Python should be re-directed to WSL.

So it wasn't exactly a walk in the park.

I believe any PR would have to start with an idea of the use case. Retraceable steps!

I would say "environment detection" is a good place to start, as we would want to re-use that information in any other launch/debug config we want to find.

If we can populate the list of Python environments with an extra set of (WSL) marked entries, that would make switching a breeze (and debugging this, too!).

[TaipanRex]

Agree with @TiemenSch, wslSupport.ts from the microsoft/vscode-node-debug#158 PR should be usable in the Python extension. Someone who is familiar with the code would be able to implement this.

[TiemenSch]

@TaipanRex, would you know anyone who could prioritize this? I tried stabbing at it, but the initial barrier of this extension is too steep for me. I could however draft a PR waiting for contributions?

[xcdr]

Support for WSL is also important to me, a higher priority is desirable.

[TiemenSch]

I believe the path translation has several solutions now, of which I personally believe it is best to stick to the TypeScript one (until path translation and piping for WSL would be built right into VS Code, if ever). It offers the most flexibility as it is written in the language used by the extension itself.

It is the hooking up of path translation and piping of interpreter I/O inside the Python extension that is in need of contribution.

[PlugaruT]

Any updates on this one? I think that it's the most upvoted issue now.

[elahia]

Hi guys,

Does anyone know is it possible to install a 32 bit version of python 2.7 on ubuntu which installed on WSL?
actually in my case python 2.7 (64 bit) installed by default but i need the 32 bit version!
any help/solution is really appreciated

[eulercb]

Hello @elahia,

Avoid updating the installed python version of ubuntu, instead install pyenv (https://github.com/pyenv/pyenv) and use it to download and manage multiple python versions.

[elahia]

Thank you Euler so much, I will try for that. Nice day

…

On Sat, Jul 28, 2018 at 7:24 PM, Euler ***@***.***> wrote: Hello @elahia <https://github.com/elahia>, Avoid updating the installed python version of ubuntu, instead install pyenv (https://github.com/pyenv/pyenv) and use it to download and manage multiple python versions. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#67 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ANcDWOxZyGTi84SqIdnMWEDKxRxDrBw2ks5uLJ4zgaJpZM4QcdzU> .

[mrlifetime]

@jswh #67 (comment)
This works to a certain extent but when I try to, for example, open a core module, I get an error like:

[jayspang]

Am I reading this correctly that Python debugging with VSCode is completely broken on Windows? The 'Python Debug Console' runs in WSL, but tries to reference Windows python installs (and uses Windows file paths).

I'd be happy to have this issue resolved and have everything working in WSL, but for now I'd be happy if the Python Debug Console just used cmd.exe so I can debug my scripts at all! Is there something wrong with my understanding of the issue?

[TiemenSch]

I was trying to get a C++ debugging setup working with WSL and came across this:
https://github.com/jstarks/npiperelay

I feel its setup is a bit too technical for most users, but it shows quite some promise to setup things safe&secure.

[jswh]

@mrlifetime Could you please create a issuse at the project. I will try fixing it.

[comfortablynick]

Would it be too much to ask to include pyenv support as well? That way you don't end up relying on the base system Python in WSL for all your work.

Yes, please! It would be so great if we could use our Linux virtual environments from within VS Code.

[bertubrio]

Install extension Code Runner. Add config into your user setting like this:

Thanks for this. I use Code Runner but hadn't thought to use it to translate the Windows paths to Unix paths.
Is there a way to get it working with my WSL venv? It tries to use the env that I set in VS Code, which obviously has to be Windows.

Just add ("code-runner.terminalRoot": "/mnt/") into your user setting. When you run code, it will replace Windows paths prefix "D:" or "C:" with "/mnt/".
And it work with your WSL venv, when you add this:

"terminal.integrated.shell.windows":"C:/Windows/System32/bash.exe",
"code-runner.runInTerminal":true

It work with your windows venv, when you add this:
"code-runner.runInTerminal":false
It work with your remote server venv, when you add this:

"terminal.integrated.shell.windows":` `"C:/Windows/System32/bash.exe",
"code-runner.runInTerminal":true

and config your SSH-FS like this:

"sshfs.configs": [
{
"label": "label",
 "root": "/",
"host": "host",
"port": port,
"username": "name",
"password": "password"
"name": "name"
}]

and login your remoter server account in vscode terminal over ssh

Amazing work guys, works like a charm!! Many Thanks!

[w-biggs]

From @M-Adoo on December 18, 2016 7:27

+1

That be nice, if i can use wsl python enviroment across some config.

like this ?

{
   "python.linting.pylintPath": "C:\\Windows\\sysnative\\bash.exe",
    "python.linting.pylintArgs": ["-c", "pylint"]
}

Is this still the correct way to get pylint to work? I'm getting an error saying that the path to the linter is invalid. When I try it with System32 instead of sysnative, I don't get an error anymore, but pylint doesn't seem to work at all anyway.

[avonar]

Just wanted to mention that I've tried a few of the options here but they all seem to have their own issues when attempting to do anything beyond running tests and linting (e.g. debugging). Until MS releases a more robust integration I'd recommend just running vscode within WSL via a X Windows server (currently using VcXsrv). You can then just shortcut it via C:\Windows\System32\cmd.exe /c bash -c "DISPLAY=:0 code"

Thank you!
i really cant understand about microsoft developers backlog. How are they generate it?
WSL dont support linux escape sequences, vs code dont support wsl, wsl have problems with i/o performance. And issues have been open for years.

[OhYee]

I have tried to use exe file to redirect the path to WSL.
The autopep8, git could work better.
However, I don't know how pylint and auto-complate work.

I could run code successfully. But I think auto-complate is necessary for me.

[aaronzo]

Presumably people want this to use a module in python that is only available on linux? (for me it's graph-tool). An idea I had:

If there was a way for pip to install just the namespace of the modules on windows, so that pylint and intellisense can recognise the functions/types/keyword arguments, then coupling this with the methods above regarding using bash as the integrated terminal in WSL, we would effectively be able to have most of what we want, even though it would effectively mean having 1 environment for intellisense (windows) and an identical one for debugging (in WSL).

[ly-cultureiq]

microsoft/vscode#63155

[micmelesse]

Where should I start if I wanted to work on a PR for this?

[drabb]

Contribution guide here

[micmelesse]

@drabb Thanks for the response. I was looking more for suggestions of files to start looking at to tackle this specific problem.

[joelcthomas]

@DonJayamanne does this relate to gitbash as well? I consistently use gitbash with vscode and I don't have any other issue. Only need to change conda activation command from 'activate ' to 'source activate '
Would it be possible to decouple the two?

[brettcannon]

@joelcthomas this is only for WSL. We currently have no plans to support gitbash explicitly.

[mazamorac]

For those of you wanting path translation from/to WSL and Win using coderunner or another solution, take a look at https://blogs.msdn.microsoft.com/commandline/2017/12/22/share-environment-vars-between-wsl-and-windows/

[rcarmo]

I think this is a good summary, with the exception of the GUI bits, in the sense that there is very little scope for interacting with Linux GUI apps, whereas it is expected that VS Code be able to seamlessly interact with CLI tools and language runtimes inside WSL.

I have an X server installed to run one thing from WSL (the Arduino IDE, because... reasons), and I believe whomever really needs to get that working is usually able to.