Find and utilise WSL Python Environments

[DonJayamanne]

From @kuza55 on November 18, 2016 14:58

Since windows processes can now call bash.exe to call processes in the WSL subsystem, it would be nice if VS code could:

a) Be configured to utilise a python interpreter inside WSL through bash.exe
b) Automatically find WSL virtualenvs in the current project and let the user use them easily

Making the Jupyter integration work in this scenario would also be very cool.

Copied from original issue: DonJayamanne/pythonVSCode#534

[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 @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.

[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

[offero]

@garytyler Does that work for things like pylint?

[offero]

Can we currently configure vscode to use pylint from WSL in any way? Or is it completely broken for wsl envs?

[garytyler]

@garytyler Does that work for things like pylint

I just use that for activating virtual environments. I use pipenv and I tested that with using regular virtualenv or venv for Python 3.

For linting, the way I've been setting it up is installing pylint on my Windows Python and setting the path with "python.linting.pylintPath" in settings.json and it works fine whether I'm using WSL Python or Windows Python in my project.

[g3rfx]

Please consider the existence of virtual environments of Anaconda as well.

[dclong]

And possibly virtual environment in Cygwin

[dkout]

Anyone knows what the timeline for this feature might be? Would be immensely important for my workflow. Thanks!

[brettcannon]

@dkout we purposefully don't give out timelines, sorry.

[perbeatus]

For me this is the only reason not to use Windows 10 for work instead of Ubuntu.

[WSLUser]

You can use the new Plan9 server as a means of providing a path for the python environment. I would do it as a query since the path differs based on distro. Of course this also means a version check for a version of Windows that supports it (which the May release will be the first to support).
Link describing the feature:
https://devblogs.microsoft.com/commandline/whats-new-for-wsl-in-windows-10-version-1903/

[phillipwei]

wslpath within WSL can be used to translate paths. This has to be invoked from within WSL, so calling it from the windows side looks like "C:\Windows\System32\bash.exe" -c "wslpath C:\\\\folder\\\\file.txt".

Too hacky for me but might help someone following this thread.

[WSLUser]

Follow on context bash.exe is depreciated. Use wsl.exe unless your version of Windows doesn't support it. 19H1 (upcoming release) specifically practically makes it mandatory to use it as functions from wslconfig.exe were moved to wsl.exe but then for the upcoming release, I already stated a solution.

[WSLUser]

Also while I'm here, there is wslenv that could potentially be used as well: https://devblogs.microsoft.com/commandline/share-environment-vars-between-wsl-and-windows/ but that would still be a bit hacky, if not more hacky than using wslpath.

[qubitron]

Hi folks, we are closing this as support for WSL is enabled by the new Visual Studio Code Remote extensions we are unveiling today at PyCon!

Learn more at...
VS Code Blog: https://code.visualstudio.com/blogs/2019/05/02/remote-development
Python Blog: https://devblogs.microsoft.com/python/remote-python-development-in-visual-studio-code/
Remote-WSL extension: https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-wsl

If you are at PyCon stop by our booth for a demo.

[nc-dtan]

This is fantastic news, but unfortunately I can't get it to work on insider after installing remote development and remote wsl as the guide say.

I click on Remote-WSL: New Window and get the following error:

Anyone witht that problem who solved it?

[aaronzo]

did you launch code-insider from your WSL bash terminal?

[nc-dtan]

Yes. I did:

1. From cmd: >wsl
2. $ cd path/to/place/with/code
3. $ code-insiders .

[gijswobben]

I had to run wsl.exe as administrator.. maybe that helps? But otherwise you might have to start an issue for that plugin..

[nc-dtan]

I had to run wsl.exe as administrator.. maybe that helps? But otherwise you might have to start an issue for that plugin..

Same result when running as administrator. I will open an issue on vscode. Thanks for the suggestion though :)

[Mathias-C]

I had the same issue because I was launching in my .bashrc file the fish shell instead of the default.
Might it be some configuration issue within your .bashrc or .bash_profile?

I also have these settings pointing to the normal bash.exe.
"terminal.integrated.shell.windows": "C:\\WINDOWS\\System32\\bash.exe"

[siaarzh]

Been waiting long enough. I'll wait for the release in stable. Thank you @qubitron and your team!!!

[nc-dtan]

I had the same issue because I was launching in my .bashrc file the fish shell instead of the default.
Might it be some configuration issue within your .bashrc or .bash_profile?

I also have these settings pointing to the normal bash.exe.
"terminal.integrated.shell.windows": "C:\\WINDOWS\\System32\\bash.exe"

YES! It worked :D Thank you. I would not have guessed that in a million years.

[siaarzh]

For me this is the only reason not to use Windows 10 for work instead of Ubuntu.

Now, there is no reason!