Repository navigation
[feature request] get python.pythonPath from cwd rather than system wide. #363
Description
Environment data
VS Code version: 1.8.1
Python Extension version: 0.8.0
Python Version: 3.6.3
OS and version: macOS 10.13.2
Actual behavior
use system python if I leave python.pythonPath blank
Expected behavior
find python at current path
use
pythonset pypyenv
I can set.python-versionin some parent-folder
Steps to reproduce:
pyenv local <some-version>at~/dev- open
~/dev/project1as a project - current
python.pythonPathis the system-wide, not read from current folder.
Activity
brettcannon commentedon Dec 7, 2017
Not quite sure what you are after here as I don't use
pyenv. Are you creating a virtual environment or something locally in the directory and you don't want that being picked up? Or do you not want the changes made bypyenvto be detected?specter119 commentedon Dec 8, 2017
Brett Cannon (@brettcannon) Thanks, this plugin doesn't pick-up the python-version which
pyenvcustomized for current folder, it will use the version set for the system.gwax commentedon Dec 8, 2017
pyenvis a tool that replaces python and installed python tools (pylint,flake8, etc.) with symbolic links and routes requests to different commands based on global/local configuration.It is used as an alternative to virtualenvs and is one of the more common ways of managing python versions on OSX.
So, for example:
The crux of it is that executing a command from a given folder will result in pyenv routing it to the correct environment (assuming bash_profile/bashrc has been run and set up pyenv).
So, the ask (I think) is that when linting/executing/whatever a given source file, execute the command from the location of that file. Alternatively, the interpreter could be set by using
pyenv which pythonfor any given path.specter119 commentedon Dec 10, 2017
George Leslie-Waksman (@gwax) Thanks Brett Cannon (@brettcannon) I find that this plugin now works as I expected. So this issue can be closed.
gwax commentedon Dec 11, 2017
I continue to have trouble with this, requiring me to manually select interpreter whenever I look at a different workspace and would appreciate if this issue could be re-opened.
7 remaining items
gwax commentedon Dec 12, 2017
Yeah, and problematically, the environment mutation is working directory dependent so even if I launch
codefrom a given folder, if I open a file from a different folder, that folder's pyenv might be entirely different.Explicit pyenv support seems reasonable and it's probably a good way to avoid having to pull pyenv setup from an enclosing environment (running
codefrom a terminal or sourcing .bash_profile).rcarmo commentedon Jan 3, 2018
I have a variant of this issue which is that I use
pyenvon both the Mac and the Windows Subsystem for Linux, and even if I startcodefrom the project directory it doesn't pick up the right Python version (that is a confirmation that the issue still exists in the Mac and a different issue with the same functional impact in WSL, since therecodehas to cope with picking up Python from the subsystem as well).I (and other folk) have been moving away from
virtualenvin favor ofpyenvon Linux as well because we often need to use older Python versions than what the OS ships with, use Anaconda instead of "plain" Python (which is also supported bypyenv), or just use the same set of specific dependencies across multiple projects -- so it makes sense to have a single install with them all rather than multiplevirtualenvsall over the place.Edited to add: Also,
pylintneeds to takepyenvinto account, since it might be linting the wrong Python version.neverfox commentedon Apr 2, 2018
Same issue here, and it's currently preventing me from using VSCode as my Python IDE since I always use pyenv and virtualenvs (so instead I'm using Spacemacs, which handles all this just fine). More specifically, I don't just use pyenv but pyenv with the pyenv-virtualenv plugin. So you have installed pyenv versions, which VSCode picks up as valid interpreters in its list (though not automatically the way pyenv would do it), but then you have virtualenvs under each version. pyenv handles this by using shims. The shims are first in the path so you always go through them to get to pyenv, which then handles interpreting your environment to find the right version and location.
I tried setting my
python.pythonPathto/usr/local/opt/pyenv/shims/pythonbut VSCode always assumes I'm in pyenv's "global" state, which means that when pyenv is doing whatever it does to settle on a version, it lacks sufficient information inside of VSCode to do anything but settle on the default global setting for pyenv. What it needs to do (not just for the interpreter but for all executables like pylint) is give pyenv all the information it needs to do the right thing, which probably just means calling the shim as if it were being called from the folder the open file is in.neverfox commentedon Apr 2, 2018
Yes, pyenv does mutate the environment but I don't think that mutation is essential to how it works (though I could be wrong). Instead, as I said, it works through a shim executable (which you could set in your
python.pythonPath) and when that shim is executed, it goes through a four step process that depends on the directory you're in, particularly steps two and three. This also raises the question of why VSCode doesn't just automatically choose the first interpreter on your path rather than searching a pre-specified list of paths (that don't happen to include $(pyenv root)/shims). That way there would be no need to even touch the user settings out of the box.gwax commentedon Apr 2, 2018
Having lived with this a bit longer, I find it's a lot less difficult to work around than I previously thought but there are a few minor issues that make things annoying and some other possible nice to haves.
pyenv,pylint,flake8, and VSCode works perfectly well together if you set the appropriate interpreter (Python: Select Interpreter). If you're usingpyenvall of your python versions andpyenv-virtualenvvirtual environments will show up on the list (with a caveat detailed below). All of this works without touchingpython.pythonPath.Annoyances and nice to haves:
pyenvor the.python-versionfilebrettcannon commentedon Apr 2, 2018
See #1167 for tracking the request to add support for
.python-versionto auto-select the interpreter. And I think these issues are now duplicates of each other so I'm going to close this one and move the discussion over.neverfox commentedon Apr 2, 2018
George Leslie-Waksman (@gwax) All of mine aren't showing up, so I'm curious how you accomplished (or lucked into) that. I'd be fine with most of the issues you mention if I at least got a complete list, but look at this:
Now:
Screenshot of
Python: Select InterpreterNotice that the PonyGE2 and nrf venvs are nowhere to be seen. It's almost like it's taking the first one in order under the
3.6.5parent and ignoring the rest.gadams999 commentedon Apr 3, 2018
Roman Pearah (@neverfox) I see the same behavior. I created a pyenv virtualenv and set that to global. vscode does see that as an interpreter. However, any other virtualenvs do not show up.
At present I use the Select Interpreter to reference the exact python version for the workspace/directory which does work. Will start tracking the other open issue for completion.
neverfox commentedon Apr 3, 2018
Gavin Adams (@gadams999) Thanks for confirming. Sounds like this should be its own issue.
brettcannon commentedon Apr 3, 2018
Roman Pearah (@neverfox) please open a separate issue as that is a feature request since we only detect virtual environments that are kept in your workspace folder or created by pipenv.
neverfox commentedon Apr 5, 2018
George Leslie-Waksman (@gwax) I'm actually really curious how that's able to do the trick for the other executables like pylint, flake8, etc since you're not telling the extension about where to find the right copy like you are with the interpreter. Perhaps it works because the extension sets something in the environment that effects the shims for them to be directed appropriately?