On Windows, invoking `deactivate` in the terminal does not restore the PATH env var

[nlebedenco]

Type: Bug

Behaviour

On Windows, after the extension automatically activates the python environment in a cmd terminal, it is possible to invoke deactivate in that same terminal to restore its original env state but the PATH env var remains modified with the path to the venv prepended so if the venv folder is not manually deleted the terminal keeps using the python interpreter of the venv.

This is related to #22448

Steps to reproduce:

1. Create a python environment in a test folder
   (python -m venv --upgrade-deps .venv)
2. In VSCode open the test folder, and make sure the python extension is installed and enabled
3. Add the option "python.terminal.activateEnvironment": true, to the workspace settings (in .vscode/settings.json)
4. Close VSCode and open again
5. Open a cmd terminal panel via Menu->Terminal->New Terminal
6. Wait for a second, so the terminal can automatically activate the venv once the extension is loaded
7. After the venv is activated, print the env . Enter set
8. Note the prompt variable is changed, the VIRTUAL_ENV var is defined and the PATH is prepended with the venv bin path
9. Enter where python
   The python executable found should be the one from the venv
10. Enter deativate to restore the terminal
11. Enter set to inspect the env. Note prompt is restored, the VIRTUALPENV var is gone but PATH is still prepended
12. Enter where python
    The first python found should be the one installed in the host system but the binary in the venv folder s still picked up because PATH is wrong.

Diagnostic data

Output for Python in the Output panel (View→Output, change the drop-down the upper-right of the Output panel to Python)

2024-10-03 19:05:25.865 [info] Experiment 'pythonRecommendTensorboardExt' is active
2024-10-03 19:05:25.865 [info] Experiment 'pythonSurveyNotification' is active
2024-10-03 19:05:25.865 [info] Experiment 'pythonTerminalEnvVarActivation' is active
2024-10-03 19:05:25.865 [info] Experiment 'pythonTestAdapter' is active
2024-10-03 19:05:25.865 [warning] Dir "c:\Dev\IRIS\.pixi\envs" is not watchable (directory does not exist)
2024-10-03 19:05:25.865 [info] Default formatter is set to null for workspace c:\Dev\IRIS
2024-10-03 19:05:25.865 [info] Python interpreter path: .\.venv\Scripts\python.exe
2024-10-03 19:05:25.912 [info] > pyenv which python
2024-10-03 19:05:25.912 [info] cwd: .
2024-10-03 19:05:25.975 [info] > pixi --version
2024-10-03 19:05:25.998 [info] > ./.venv/Scripts/activate.bat && echo 'e8b39361-0157-4923-80e1-22d70d46dee6' && python ~/.vscode/extensions/ms-python.python-2024.16.0-win32-x64/python_files/printEnvVariables.py
2024-10-03 19:05:25.998 [info] shell: commandPrompt
2024-10-03 19:05:26.176 [info] > C:\Python\python.exe ~/.vscode/extensions/ms-python.python-2024.16.0-win32-x64/python_files/printEnvVariables.py
2024-10-03 19:05:26.176 [info] shell: commandPrompt
2024-10-03 19:05:26.264 [info] Setting environment variable ELECTRON_RUN_AS_NODE in collection to 1 {"applyAtShellIntegration":true,"applyAtProcessCreation":true}
2024-10-03 19:05:26.264 [info] Prepending environment variable PATH in collection with C:\Dev\IRIS\.venv\Scripts; {"applyAtShellIntegration":true,"applyAtProcessCreation":true}
2024-10-03 19:05:26.264 [info] Setting environment variable PROMPT in collection to (.venv) $P$G {"applyAtShellIntegration":true,"applyAtProcessCreation":true}
2024-10-03 19:05:26.264 [info] Setting environment variable VIRTUAL_ENV in collection to C:\Dev\IRIS\.venv {"applyAtShellIntegration":true,"applyAtProcessCreation":true}
2024-10-03 19:05:26.264 [info] Setting environment variable VIRTUAL_ENV_PROMPT in collection to (.venv)  {"applyAtShellIntegration":true,"applyAtProcessCreation":true}
2024-10-03 19:05:26.264 [info] Setting environment variable _OLD_VIRTUAL_PROMPT in collection to $P$G {"applyAtShellIntegration":true,"applyAtProcessCreation":true}
2024-10-03 19:05:26.987 [info] Starting Jedi language server for IRIS.

Extension version: 2024.16.0
VS Code version: Code 1.94.0 (d78a74bcdfad14d5d3b1b782f87255d802b57511, 2024-10-02T13:08:12.626Z)
OS version: Windows_NT x64 10.0.22631
Modes:

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

User Settings

languageServer: "Jedi"

Installed Extensions

Extension Name	Extension Id	Version
.NET Install Tool	ms-dotnettools.vscode-dotnet-runtime	2.1.7
C/C++	ms-vscode.cpptools	1.21.6
CMake Language Support	josetr.cmake-language-support-vscode	0.0.9
EditorConfig for VS Code	EditorConfig.EditorConfig	0.16.4
GNU Linker Map files	trond-snekvik.gnu-mapfiles	1.1.0
JavaScript Debugger	ms-vscode.js-debug	1.94.0
JavaScript Debugger Companion Extension	ms-vscode.js-debug-companion	1.1.3
nRF Connect for VS Code	nordic-semiconductor.nrf-connect	2024.9.87
nRF Connect for VS Code Extension Pack	nordic-semiconductor.nrf-connect-extension-pack	2024.9.5
nRF DeviceTree	nordic-semiconductor.nrf-devicetree	2024.9.26
nRF Kconfig	nordic-semiconductor.nrf-kconfig	2024.9.20
nRF Terminal	nordic-semiconductor.nrf-terminal	2024.9.14
Python	ms-python.python	2024.16.0
Python Debugger	ms-python.debugpy	2024.10.0
Table Visualizer for JavaScript Profiles	ms-vscode.vscode-js-profile-table	1.0.10
vscode-icons	vscode-icons-team.vscode-icons	12.9.0
WSL	ms-vscode-remote.remote-wsl	0.88.4

System Info

Item	Value
CPUs	Intel(R) Core(TM) i7-10870H CPU @ 2.20GHz (16 x 2208)
GPU Status	2d_canvas: enabled canvas_oop_rasterization: enabled_on 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: enabled vulkan: disabled_off webgl: enabled webgl2: enabled webgpu: enabled webnn: disabled_off
Load (avg)	undefined
Memory (System)	31.77GB (15.80GB free)
Process Argv	--crash-reporter-id d0acec8c-121e-4802-b4ff-bd8e528e5115
Screen Reader	no
VM	40%

A/B Experiments

vsliv368:30146709
vspor879:30202332
vspor708:30202333
vspor363:30204092
vscod805:30301674
binariesv615:30325510
vsaa593:30376534
py29gd2263:31024239
c4g48928:30535728
azure-dev_surveyonecf:30548226
a9j8j154:30646983
962ge761:30959799
pythongtdpath:30769146
welcomedialog:30910333
pythonnoceb:30805159
asynctok:30898717
pythonmypyd1:30879173
h48ei257:31000450
pythontbext0:30879054
accentitlementsc:30995553
dsvsc016:30899300
dsvsc017:30899301
dsvsc018:30899302
cppperfnew:31000557
dsvsc020:30976470
pythonait:31006305
dsvsc021:30996838
da93g388:31013173
a69g1124:31058053
dvdeprecation:31068756
dwnewjupyter:31046869
impr_priority:31102340
nativerepl1:31139838
refactort:31108082
pythonrstrctxt:31112756
flightc:31134773
wkspc-onlycs-t:31132770
wkspc-ranged-t:31151552
cf971741:31144450
autoexpandse:31146404
notype1:31151523
cc771715:31146322

[karthiknadig]

@nlebedenco Try settings this "python.experiments.optOutFrom": ["pythonTerminalEnvVarActivation"],.

We have two types of activation mechanisms.

1. Activation type1: We run the activate command in the terminal when it is created. This sets up deactivate as you would expect.
2. Activation type2: We run activation command in the background and update just the environment variables when a terminal is created.

It looks like there might be a bug in type2 activation where it is not adding _OLD_VIRTUAL_PATH to the activated environment. This is resulting in it not being restored correctly.

Setting: "python.experiments.optOutFrom": ["pythonTerminalEnvVarActivation"], turns on Activation type 1.

[nlebedenco]

Thanks @karthiknadig . The suggestion worked exactly like you described. An it also addressed a secondary issue that if I have a terminal profile with a custom prompt (by setting the PROMPT or PS1 variables), having the python extension call activate in the terminal instance itself when it is created instead of in the background when the extension is loaded results in the the new prompt displaying the right concatenation, for example (.venv) [custom prompt] C:\> as opposed to just (.venv) C:\>

Now I wonder when and why activation type 2 would be preferable over type 1

[karthiknadig]

@nlebedenco The issue with Type1 is this. Suppose multiple extensions are trying to send a command to the terminal. If Python Extension is able to send it first, then things are fine. But if the command from the other extension gets to the terminal before Python extension does then the command might fail if the environment is not activated.

The order is non-deterministic, as it entirely depends on which extension activated and registered the handler for the terminal open first.

[karthiknadig]

Closing this since the Type 1 activation addresses your concerns.