Python interpreter settings ignored if VS Code is launched from an activated environment

[julianstirling]

Type: Bug

Behaviour

When I open VSCode the python interpreter selected is inconsistent. It certainly to depends on:

• What python environment I have set in the terminal I launch it

I am not certain if other things also affect it, for a while I thought it was the history of what I did last time I had vscode open (as persistent terminals also caused me issues, but this I cannot reproduce). I have had continued issues with getting environments to persist in workspaces since the interpreter settings were changed from the settings.json a couple of years back 2022.

Every time I open a project I have to use "Python: Select Interpreter" again. I assume part of the problem is that the way my system is configured, I almost always have a python virtual environment activated. As I always launch vscode from the terminal, it seems to try to use the interpreter from the environment I launched it from, rather than the interpreter I have set.

I understand that this may be a feature not a bug, some people may want the virtual environment from the launching terminal to override workspace settings. The ideal solution would be a global settings in settings.json to never try to guess my python interpreter from virtual environments. Or anything else except how I set it for the workspace (or my default interpreter setting).

Steps to reproduce:

1. Open VSCode
2. Set interpreter with "Python: Select Interpreter"
3. Close VSCode
4. Open a new terminal
5. If this terminal doesn't have a Python venv running then start one (mine always does from my .bashrc)
6. Navigate to the workspace directory
7. run code .
8. The interpreter is not the one that was set selected for the workspace 😢

Diagnostic data

Extension version: 2024.10.0
VS Code version: Code 1.90.2 (5437499feb04f7a586f677b155b039bc2b3669eb, 2024-06-18T22:33:48.698Z)
OS version: Linux x64 5.4.0-182-generic
Modes:

• Python version (& distribution if applicable, e.g. Anaconda): 3.10.13
• Type of virtual environment used (e.g. conda, venv, virtualenv, etc.): Venv
• Value of the python.languageServer setting: None

User Settings

languageServer: "None"

Installed Extensions

Extension Name	Extension Id	Version
Better Jinja	samuelcolvin.jinjahtml	0.20.0
isort	ms-python.isort	2023.10.1
JavaScript Debugger	ms-vscode.js-debug	1.90.0
JavaScript Debugger Companion Extension	ms-vscode.js-debug-companion	1.1.2
Jupyter	ms-toolsai.jupyter	2024.5.0
Jupyter Cell Tags	ms-toolsai.vscode-jupyter-cell-tags	0.1.9
Jupyter Keymap	ms-toolsai.jupyter-keymap	1.1.2
Jupyter Notebook Renderers	ms-toolsai.jupyter-renderers	1.0.18
Jupyter Slide Show	ms-toolsai.vscode-jupyter-slideshow	0.1.6
Lark grammar syntax support	dirk-thomas.vscode-lark	0.1.0
Live Share	ms-vsliveshare.vsliveshare	1.0.5936
Markdown All in One	yzhang.markdown-all-in-one	3.6.2
Markdown Preview Enhanced	shd101wyy.markdown-preview-enhanced	0.8.13
OpenSCAD	Antyos.openscad	1.3.1
Pylint	ms-python.pylint	2023.10.1
Python	ms-python.python	2024.10.0
Python Debugger	ms-python.debugpy	2024.8.0
Remote - SSH	ms-vscode-remote.remote-ssh	0.112.0
Remote - SSH: Editing Configuration Files	ms-vscode-remote.remote-ssh-edit	0.86.0
Remote Explorer	ms-vscode.remote-explorer	0.4.3
Table Visualizer for JavaScript Profiles	ms-vscode.vscode-js-profile-table	1.0.9
Vue - Official	Vue.volar	2.0.8

System Info

Item	Value
CPUs	Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz (4 x 2900)
GPU Status	2d_canvas: enabled canvas_oop_rasterization: disabled_off direct_rendering_display_compositor: disabled_off_ok gpu_compositing: enabled multiple_raster_threads: enabled_on opengl: enabled_on rasterization: enabled raw_draw: disabled_off_ok skia_graphite: disabled_off video_decode: enabled video_encode: disabled_software vulkan: disabled_off webgl: enabled webgl2: enabled webgpu: disabled_off
Load (avg)	1, 1, 1
Memory (System)	15.39GB (6.09GB free)
Process Argv	.
Screen Reader	no
VM	0%
DESKTOP_SESSION	plasma
XDG_CURRENT_DESKTOP	KDE
XDG_SESSION_DESKTOP	KDE
XDG_SESSION_TYPE	x11

[karthiknadig]

@julianstirling If you open VS Code from an activated environment, the environment variables that we see are from that activated environment. Now when you change the selected environment, we try to change the environment. But this behavior can be non deterministic, how we select and use something strongly relies on how the environment variables are set.

That said, the extension should just use the selected environment.

We are working on re-doing how this mechanism works. I think the re-write of this should be able deal with scenarios like this better. But I am not entirely sure that we can clear out all the possible environment variables for the various combination of activated environments to selected environment conversion.

[falkben]

Yes, automatic activation for conda environments doesn't seem to be working for me either anymore.

I've tried a few of the last versions of the extension, and I cannot get it to work with any of them, so I wonder if it was a vscode update.

EDIT: I don't know what's going on, but it just started working again for me

[sqr00t]

Update: I switched Python extension to a month ago (2024.10.0) and things are working again :)

[bonassifabio]

Had the same problem after some extension update. Looks like vscode-python 2024.12.3 is breaking Python interpreters on MacOS.

I solved by installing the latest dev version (v2024.13.2024081501).

[ndgayan]

Same here. I am using remote SSH. The newer extension is not showing VENVs. 2024.10.0 is working fine.

[davidfokkema]

We are working on re-doing how this mechanism works. I think the re-write of this should be able deal with scenarios like this better. But I am not entirely sure that we can clear out all the possible environment variables for the various combination of activated environments to selected environment conversion.

Would that also solve #23571?

[lephuongbg]

The latest python extension keep choosing .venv/bin/python regardless of what interpreter I have selected (I do have that path but it is not usable because it linked to the python binary inside docker container, and I don't use remote container because I have multi-root workspace, each root is running in a separate container).

Additional problem is all the other extensions (pylint, isort, black) also keep using .venv/bin/python instead of the whatever interpreter was selected.

[julianstirling]

Agreed that external tools are the most important. It is a little annoying that the wrong virtual env is set in the terminal, but also easy to fix. Having the wrong environment for linting is much harder to identify and fix.