Python path from other project's ./.venv being used elsewhere

[yajo]

Issue Type: Bug

I have one project that has a .venv folder, and in that project settings, that's the python path. OK.

But then, when I switch to another project, instead of picking a more global python path such as /usr/bin/python by default, it defaults to the other project's .venv/bin/python, which is obviously not for this project.

Extension version: 2020.9.114305
VS Code version: Code 1.50.1 (d2e414d9e4239a252d1ab117bd7067f125afd80a, 2020-10-13T14:44:48.716Z)
OS version: Linux x64 5.8.15-201.fc32.x86_64

System Info

Item	Value
CPUs	Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz (12 x 3949)
GPU Status	2d_canvas: enabled flash_3d: enabled flash_stage3d: enabled flash_stage3d_baseline: enabled gpu_compositing: enabled multiple_raster_threads: enabled_on oop_rasterization: disabled_off opengl: enabled_on protected_video_decode: unavailable_off rasterization: disabled_software skia_renderer: enabled_on video_decode: unavailable_off vulkan: disabled_off webgl: enabled webgl2: enabled
Load (avg)	2, 2, 2
Memory (System)	15.48GB (1.64GB free)
Process Argv	--no-sandbox --unity-launch --crash-reporter-id abab7a42-9f41-495c-b7c0-99224e53627a
Screen Reader	no
VM	0%
DESKTOP_SESSION	gnome
XDG_CURRENT_DESKTOP	GNOME
XDG_SESSION_DESKTOP	gnome
XDG_SESSION_TYPE	x11

[ddesroches]

I saw something similar -- when Home Brew updated my Python3 to 3.8.6, I rebuilt my venv with the new Python version but VS Code still showed 3.7.5 in some cases until I updated all of my venvs.

[kimadeline]

Hi @yajo

Thanks for the bug report! We investigate issues in order based on priority and severity, which includes the impact it has on your ability to use the extension to do productive work, and the number of people affected. If other users come forward and leave a comment demonstrating they are seeing/reproducing the problem then we will raise this issue's priority.

@ddesroches, please note that the extension caches the interpreter information it receives, which might lead to some inconsistencies until the cache is invalidated. In any case, it isn't related to the problem initially reported.

Thanks for your understanding and patience!

[ovidner]

I can confirm this behavior, at least with workspaces. Even though I've set an interpreter for the entire workspace (and none for the constituent folders), some folder's interpreter setting might all of a sudden be selected to point to a completely irrelevant project's environment. It can sometimes lead to subtle and very frustrating errors, when you realize after a moment that it's just pointing to the incorrect environment. It seems like the workspace interpreter setting is not respected and that the interpreter instead is selected by some kind of heuristic or something. It's not really helpful. :( I don't want to set the interpreter on a folder level, since I have some folders/projects in multiple workspaces and want (i.e. expect) them to use the interpreter based on the context/workspace they're opened in for the moment.

[Almenon]

A user of AREPL just ran into this too. They have three folders, one with a python 3.5 venv and the other with a python 3.6 venv. AREPL uses the python path from the python extension, but the python extension is reporting 3.5.

Here's an example repo you can use to reproduce the issue: https://github.com/Almenon/pythonBugRepro1.git

1. Clone repo
2. Create a python 3.6 venv in pi_0 folder
3. Create a python 3.7 venv in pi_1 folder (I don't think the exact version matters, you just need two folders with different python versions)
4. Open up the workspace in vscode
5. Open up the python file in the pi_0 folder
6. Select the 3.6 venv as the interpreter for that folder
7. Open up the python file in the pi_1 folder
8. Select the 3.7 venv as interpreter for that folder
9. Set the entire workspace interpreter to 3.7 venv (you might need to do this by selecting the file manually, the venv didn't show up for me)
10. Try running workspaceDefault.py or test1.py - they run with python 3.6 instead of 3.7

Expected result: it runs with python 3.6
Actual result: it runs with python 3.7

I also tried selecting python 3.9 as the workspace interpreter and that didn't work either. Note that my default profile is command prompt.

Environment data

• VS Code version: 1.59.0 (latest)
• Extension version (available under the Extensions sidebar): v2021.8.1105858891
• OS and version: Windows 10
• Python version (& distribution if applicable, e.g. Anaconda): Python 3.6/3.7
• Type of virtual environment used (N/A | venv | virtualenv | conda | ...): venv
• Relevant/affected Python packages and their versions: N/A
• Relevant/affected Python-related VS Code extensions and their versions: AREPL v2.0.3
• Value of the python.languageServer setting: Default

Perhaps related: #3325

[kimadeline]

Sorry for the delay, is this still happening with the latest version of the extension? We have changed the way we do interpreter discovery and auto-selection in the past couple of releases.

[yajo]

I haven't hit this problem lately.

[kimadeline]

I will close the issue for now then. If you encounter this problem again, feel free to comment here and we'll reopen it, or open a new issue.

Thank you!