python.pythonPath doesn't work properly in workspace with multiple python projects

[pferretti]

Environment data

VS Code version: 1.19.3
Python Extension version: 2018.1.0
Python Version: 3.6.4
OS and version: Ubuntu 16.04

Actual behavior

In a workspace with multiple projects associated to multiple virtual environments, the association with virtual environments doesn't work anymore. VSCode Python keep using the virtual environment defined in the first project of the workspace.
If I open the single projects, the association with virtual environment works as expected.

Expected behavior

Correct association to a proper virtual environment for every project in a workspace.

Steps to reproduce:

• Add at least two projects in a workspace
• Configure a different virtual environment for every project using python.pythonPath
• Save the workspace
• Reload the window and check the virtual environment loaded by VSCode for each project

Logs

Output from Python output panel

Output from Console window (Help->Developer Tools menu)

/usr/share/code/resources/app/out/vs/workbench/workbench.main.js:249 [Extension Host] Python Extension: Failed to get conda info from conda null
t.log @ /usr/share/code/resources/app/out/vs/workbench/workbench.main.js:249
/usr/share/code/resources/app/out/vs/workbench/workbench.main.js:249 [Extension Host] (node:26467) DeprecationWarning: os.tmpDir() is deprecated. Use os.tmpdir() instead.
t.log @ /usr/share/code/resources/app/out/vs/workbench/workbench.main.js:249

[DonJayamanne]

Reload the window and check the virtual environment loaded by VSCode for each project

What do you mean by check the virtual env loaded?
Do you mean to say that the pythonPath setting in settings.json has now changed?

[pferretti]

What do you mean by check the virtual env loaded?

I'm sorry, probably not the best explanation!

I mean that you must check the pythonPath used by VSC for the project relative to the .py file that you opened.

So, if you open a .py file contained in the first project of your workspace, VSC uses the correct pythonPath, but if you open a .py contained in the second (or third, fourth, etc...) project of your workspace, VSC uses the pythonPath defined in the first project, not the one defined for the project that you are using.

[DonJayamanne]

How are you identifying this issue?
Please could you provide the steps?

[galindro]

@DonJayamanne I've seen the same problem here, in my env. I'll try to clarify @pferretti explanation for you through a simple example:

1. Create two python virtualenvs. You could use virtualenvwrapper for this. P.S.: I'm using python 3.6, but you could use 2.7. This error isn't tied to the python version.

mkvirtualenv -p /usr/bin/python3.6 project_1
mkvirtualenv -p /usr/bin/python3.6 project_2

2. Create .vscode with a settings.json file on each virtualenv folder, like bellow:

settings.json from project_1

{
    "python.pythonPath": "/<your_root_folder>/project_1/bin/python"
}

settings.json from project_2

{
    "python.pythonPath": "/<your_root_folder>/project_2/bin/python"
}

3. Create a simple python script on each virtualenv, like bellow:

main.py from project_1

print("Hello World!")

main.py from project_2

print("Hello World!")

4. Check if the root folder content of your workspace is like bellow:

Folder contents:

project_1
├── bin
│   ├── activate
│   ├── activate.csh
│   ├── activate.fish
│   ├── activate_this.py
│   ├── easy_install
│   ├── easy_install-3.6
│   ├── epylint
│   ├── get_env_details
│   ├── isort
│   ├── pip
│   ├── pip3
│   ├── pip3.6
│   ├── postactivate
│   ├── postdeactivate
│   ├── preactivate
│   ├── predeactivate
│   ├── pylint
│   ├── pyreverse
│   ├── python -> python3.6
│   ├── python3 -> python3.6
│   ├── python3.6
│   ├── python-config
│   ├── symilar
│   └── wheel
├── include
│   └── python3.6m -> /usr/include/python3.6m
├── lib
│   └── python3.6
├── main.py
├── pip-selfcheck.json
└── .vscode
    └── settings.json
project_2
├── bin
│   ├── activate
│   ├── activate.csh
│   ├── activate.fish
│   ├── activate_this.py
│   ├── easy_install
│   ├── easy_install-3.6
│   ├── epylint
│   ├── get_env_details
│   ├── isort
│   ├── pip
│   ├── pip3
│   ├── pip3.6
│   ├── postactivate
│   ├── postdeactivate
│   ├── preactivate
│   ├── predeactivate
│   ├── pylint
│   ├── pyreverse
│   ├── python -> python3.6
│   ├── python3 -> python3.6
│   ├── python3.6
│   ├── python-config
│   ├── symilar
│   └── wheel
├── include
│   └── python3.6m -> /usr/include/python3.6m
├── lib
│   └── python3.6
├── main.py
├── pip-selfcheck.json
└── .vscode
    └── settings.json

5. Now, open vscode and add those two folder projects in a new workspace, begging with project_1. See the print bellow:

6 - Open the project_1/main.py file and check the python path in the botton of the screen. You must just stay with the mouse pointer on it and a pop-up will open telling you the python path:

As you can see above, it points to the python interpreter installed on project_1 folder. This is fine.

7 - Now open the project_2/main.py and make the same steps above:

See that the python interpreter used by this folder is the same as project_1, instead of project_2. Even if I try to click on that menu and try to change the python interpreter of project_2 folder, it not works, because the menu always point to project_1 folder. Check the bellow prints:

I hope that I was clear enough.

[galindro]

My vscode version is: 1.19.3-1516876437
My O.S. is Debian 9

[galindro]

@DonJayamanne

I've tested with all of the bellow versions and the error occurs with all of them

     1.19.3-1516876437 990
        990 https://packages.microsoft.com/repos/vscode stable/main amd64 Packages
     1.19.2-1515599945 990
        990 https://packages.microsoft.com/repos/vscode stable/main amd64 Packages
     1.19.1-1513676564 990
        990 https://packages.microsoft.com/repos/vscode stable/main amd64 Packages
 *** 1.19.0-1513245498 990
        990 https://packages.microsoft.com/repos/vscode stable/main amd64 Packages
        100 /var/lib/dpkg/status

[pferretti]

Thanks @galindro , a perfect explanation :-)

[lig]

Same here. Reproduces in 1.20. Makes vscode python extension almost unusable and results in false errors from all over the workspace. I had 9 folders in the same workspace and now I'm forced to remove and readd folders continuously to be able to use the extension.

[kentwait]

Sent here after filing the issue on the vscode repository.

I would like to add that it doesn't necessarily have to be multiple Python projects, just any multi-root workspace. At least on Mac OS X 10.11.6.

In my setup I have a two root folders in the workspace, one folder using Go and the other folder using Python. Only the Python folder has the python.pythonPath folder setting and the behavior described above still occurs.

EDIT:
Looking at the settings.json file, selecting the interpreter using the menu does change the value of python.pythonPath but the menu value does not. More importantly, even if the interpreter value in settings.json changes, vscode does not register that change and is stuck with the intepreter loaded at launch.

[Tantalus13A98B5F]

Same here. And I've done some work of debugging. The explanation is here (I filed the issue in vscode's repo by mistake 😂

[galindro]

@DonJayamanne is this fix already available for download/install?

[Tantalus13A98B5F]

Well, I downloaded the latest source (master) and started it with vscode's Launch Extension. I opened a workspace where the first folder has no settings and the second one's pythonPath set to a virtualenv. Now when I open a python file in the second folder, the selected interpreter is correct. However, the status bar shows nothing (in fact a blank) for the interpreter, and my virtualenv is still not an available choice when selecting interpreter.

[lig]

@Tantalus13A98B5F Insiders Build of the python extension worked for me fully. Interpreter updates status bar correctly. I see the current folder's venv in venvs list. Not quite sure if all venvs are shown there.

[DonJayamanne]

@lig

I see the current folder's venv in venvs list. Not quite sure if all venvs are shown there.
No, we don't list all venvs. If you would like this, please create a separate issue for this.

[lig]

@DonJayamanne For me personally it's ok. I usually put the correct interpreter for the folder into its settings by hands. Explicit is better than implicit, you know:)

[galindro]

@DonJayamanne is there an ETA for this fix be available to download/install?

[jkehler]

Just chiming in here that I also ran into this problem. I have a multi-project workspace that has a javascript project as well a python project. No matter what I do I cannot get the python project to select the interpreter since my javascript project is the first folder in the workspace.

[DonJayamanne]

@lig @galindro @jkehler @Tantalus13A98B5F
The issue has been fixed and the fix will be delivered along with the next version (end of the month).
For the moment, please feel free to download the latest Insiders Build of the extension (its contains all fixes and current dev work to be released in the next version).

[lig]

@DonJayamanne I've just noticed that installing autopep8 via suggestion after invoking code format by clicking on the "install" button in the suggestion still uses an interpreter configured in the first folder of the workspace.
I use 2018.2.0-aplha version.

[lig]

Reproduces on the latest 2018.2.0-beta.

[lig]

@DonJayamanne is it already in Insiders Build? I'm eager to test it. Thanks!

[DonJayamanne]

@lig Yes it is, please let me know how it goes

[lig]

@DonJayamanne no luck
I've just redownloaded it via the https://pvsc.blob.core.windows.net/extension-builds/ms-python-insiders.vsix link and installed. The same scenario still doesn't work as expected.
Are you sure the build is ready?

[lig]

Could you point me on how can I check the exact installed extension's version and build?

[DonJayamanne]

Unfortunately theres no way. Just uninstall and download, and re-install.
We don't update the version (build) numbers for each build.

[lig]

What I did:

• Uninstall extension
• Close VSCode
• Download Insiders Build
• Install Insiders Build
• Open VSCode
• Ensure all editors are closed
• Ensure all terminals are closed
• Open .py file from a non-first folder
• Invoke Format Document
• Notice the Install autopep8 suggestion
• Press Install autopep8

Expected result:

• Terminal opens in the file's folder
• autopep8 is installed using the file folder's interpreter

Actual result:

• [pass] Terminal opens in the file's folder
• [fail] autopep8 is installed using the first folder's interpreter

[DonJayamanne]

@lig I believe I know what's happened, our CI tests are failing hence the extension isn't getting built. Please test this build of the extension.

• Please download this extension
  python-2018.2.0-beta.zip

• Rename the file extension from .zip to .vsix

Apologies for this issue. Hopefully we'll have the CI tests resolved tomorrow (we've already got a PR lined up to resolve that)

[lig]

@DonJayamanne the last build you've provided here works as expected. Thank you!