Skip to content
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

Find and utilise WSL Python Environments #67

Closed
DonJayamanne opened this issue Nov 13, 2017 · 124 comments
Closed

Find and utilise WSL Python Environments #67

DonJayamanne opened this issue Nov 13, 2017 · 124 comments

Comments

@DonJayamanne
Copy link

@DonJayamanne DonJayamanne commented Nov 13, 2017

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

This comment has been minimized.

Copy link
Author

@DonJayamanne DonJayamanne commented Nov 13, 2017

From @rogersachan on November 21, 2016 2:9

I'll close #195 since this is better worded

@DonJayamanne

This comment has been minimized.

Copy link
Author

@DonJayamanne DonJayamanne commented Nov 13, 2017

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

This comment has been minimized.

Copy link
Author

@DonJayamanne DonJayamanne commented Nov 13, 2017

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

This comment has been minimized.

Copy link
Author

@DonJayamanne DonJayamanne commented Nov 13, 2017

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

This comment has been minimized.

Copy link
Author

@DonJayamanne DonJayamanne commented Nov 13, 2017

From @tmcdonnell87 on January 25, 2017 5:12

+1

@DonJayamanne

This comment has been minimized.

Copy link
Author

@DonJayamanne DonJayamanne commented Nov 13, 2017

From @dalyIsaac on February 9, 2017 2:32

+1

@DonJayamanne

This comment has been minimized.

Copy link
Author

@DonJayamanne DonJayamanne commented Nov 13, 2017

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

This comment has been minimized.

Copy link
Author

@DonJayamanne DonJayamanne commented Nov 13, 2017

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

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

@DonJayamanne

This comment has been minimized.

Copy link
Author

@DonJayamanne DonJayamanne commented Nov 13, 2017

Unfortunately nothing yet.

@DonJayamanne

This comment has been minimized.

Copy link
Author

@DonJayamanne DonJayamanne commented Nov 13, 2017

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

This comment has been minimized.

Copy link
Author

@DonJayamanne DonJayamanne commented Nov 13, 2017

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

This comment has been minimized.

Copy link
Author

@DonJayamanne DonJayamanne commented Nov 13, 2017

From @rjgonza on June 23, 2017 16:9

+1

@DonJayamanne

This comment has been minimized.

Copy link
Author

@DonJayamanne DonJayamanne commented Nov 13, 2017

From @hacdias on October 28, 2017 19:23

+1

@DonJayamanne

This comment has been minimized.

Copy link
Author

@DonJayamanne DonJayamanne commented Nov 13, 2017

From @trungtrinh44 on October 29, 2017 15:47

+1

@DonJayamanne

This comment has been minimized.

Copy link
Author

@DonJayamanne DonJayamanne commented Nov 13, 2017

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

This comment has been minimized.

Copy link

@sgharms sgharms commented Nov 28, 2017

@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

This comment has been minimized.

Copy link

@sgharms sgharms commented Nov 28, 2017

@DonJayamanne

This comment has been minimized.

Copy link
Author

@DonJayamanne DonJayamanne commented Nov 28, 2017

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

@offero

This comment has been minimized.

Copy link

@offero offero commented Feb 13, 2019

@garytyler Does that work for things like pylint?

@offero

This comment has been minimized.

Copy link

@offero offero commented Feb 13, 2019

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

@garytyler

This comment has been minimized.

Copy link

@garytyler garytyler commented Feb 18, 2019

@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

This comment has been minimized.

Copy link

@g3rfx g3rfx commented Feb 21, 2019

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

@dclong

This comment has been minimized.

Copy link

@dclong dclong commented Mar 11, 2019

And possibly virtual environment in Cygwin

@dkout

This comment has been minimized.

Copy link

@dkout dkout commented Mar 15, 2019

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

@brettcannon

This comment has been minimized.

Copy link
Member

@brettcannon brettcannon commented Mar 15, 2019

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

@perbeatus

This comment has been minimized.

Copy link

@perbeatus perbeatus commented Mar 22, 2019

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

@WSLUser

This comment has been minimized.

Copy link

@WSLUser WSLUser commented Mar 25, 2019

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

This comment has been minimized.

Copy link

@phillipwei phillipwei commented Apr 15, 2019

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

This comment has been minimized.

Copy link

@WSLUser WSLUser commented Apr 16, 2019

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

This comment has been minimized.

Copy link

@WSLUser WSLUser commented Apr 16, 2019

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

This comment has been minimized.

Copy link

@qubitron qubitron commented May 2, 2019

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.

@qubitron qubitron closed this May 2, 2019
@pvscbot pvscbot removed the needs PR label May 2, 2019
@nc-dtan

This comment has been minimized.

Copy link

@nc-dtan nc-dtan commented May 3, 2019

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:
image

Anyone witht that problem who solved it?

@aaronzo

This comment has been minimized.

Copy link

@aaronzo aaronzo commented May 3, 2019

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

@nc-dtan

This comment has been minimized.

Copy link

@nc-dtan nc-dtan commented May 3, 2019

Yes. I did:

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

This comment has been minimized.

Copy link

@gijswobben gijswobben commented May 3, 2019

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

This comment has been minimized.

Copy link

@nc-dtan nc-dtan commented May 3, 2019

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

This comment has been minimized.

Copy link

@Mathias-C Mathias-C commented May 3, 2019

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

This comment has been minimized.

Copy link

@siaarzh siaarzh commented May 3, 2019

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

@nc-dtan

This comment has been minimized.

Copy link

@nc-dtan nc-dtan commented May 3, 2019

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

This comment has been minimized.

Copy link

@siaarzh siaarzh commented May 3, 2019

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

Now, there is no reason!

@microsoft microsoft locked as resolved and limited conversation to collaborators May 10, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
You can’t perform that action at this time.