You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since the no-config debugging update, my local venv python instances are not accessible via the terminal unless I explicitly activate the environment. I open a new terminal, and it appears my environment is activated, but it's not:
Microsoft Windows [Version 10.0.22631.4751]
(c) Microsoft Corporation. All rights reserved.
(.venv) C:\Projects>
This is also visible with an ECHO %PATH% from the console.
When I run Terminal: Show Environment Contributions, I see the following:
# Terminal Environment Changes
## Extension: ms-python.python
## Extension: ms-python.debugpy
Enables use of [no-config debugging](https://github.com/microsoft/vscode-python-debugger/wiki/No%E2%80%90Config-Debugging), `debugpy <script.py>`, in the terminal.
Enables use of [no-config debugging](https://github.com/microsoft/vscode-python-debugger/wiki/No%E2%80%90Config-Debugging), `debugpy <script.py>`, in the terminal. (workspace)
- `PYDEVD_DISABLE_FILE_VALIDATION=1`
- `DEBUGPY_ADAPTER_ENDPOINTS=C:\Users\<me>\AppData\Local\Temp\noConfigDebugAdapterEndpoints-34367d754ac0c5bc02ac\debuggerAdapterEndpoint.txt`
- `PATH=${env:PATH};c:\Users\me\.vscode\extensions\ms-python.debugpy-2025.0.0-win32-x64\bundled\scripts\noConfigScripts`
- `BUNDLED_DEBUGPY_PATH=c:\Users\me\.vscode\extensions\ms-python.debugpy-2025.0.0-win32-x64\bundled\libs\debugpy`
The PATH command above is probably overwriting the path and removing the local environment path.
All of my coworkers have encountered this problem as well, and it's a bit nefarious because it looks like the virtual environment is activated (the console shows the (venv name) prepended), but the path to the venv has been removed from the PATH. I see that the other issue was closed as not planned, but this seems like a valid issue--is there a fix in the works? Thank you!
Marshall (@mcrumiller) We are getting rid of that experiment because of the problems like the ones you faced.
The thing that we wanted to achieve was avoid sending a command to the terminal to activate. The reason is potential collision with user typing in the terminal, other extensions attempting to send things to terminal, debugger not getting the right terminal because debugger command ran before the terminal activation etc. This experiment was supposed to address that.
Unfortunately, the solution was not ideal. We attempt to run the activation script in a "sandbox" like mode and extract the environment changes. These changes however are acquired for the default terminal shell. This is where the problem starts. We now have to merge these changes with all the other shell environment variables. It does not do it right, sometimes it is not possible to do it right. It can also sometimes cause a problem where terminals get stuck in "reactivating" mode.
We are working on a different approach. This is the tracking issue for fixing the problem: microsoft/vscode-python#24699
Activity
[-][Windows] debugpy overwrites PATH, preventing virtual environment usage[/-][+][Windows] extension overwrites PATH, preventing virtual environment usage[/+]karthiknadig commentedon Feb 12, 2025
Marshall (@mcrumiller) You might be running into this issue microsoft/vscode-python#24810
mcrumiller commentedon Feb 12, 2025
Thanks Karthik Nadig (@karthiknadig), this did indeed resolve the issue after reloading VS Code.
All of my coworkers have encountered this problem as well, and it's a bit nefarious because it looks like the virtual environment is activated (the console shows the
(venv name)prepended), but the path to the venv has been removed from thePATH. I see that the other issue was closed as not planned, but this seems like a valid issue--is there a fix in the works? Thank you!karthiknadig commentedon Feb 12, 2025
Marshall (@mcrumiller) We are getting rid of that experiment because of the problems like the ones you faced.
The thing that we wanted to achieve was avoid sending a command to the terminal to activate. The reason is potential collision with user typing in the terminal, other extensions attempting to send things to terminal, debugger not getting the right terminal because debugger command ran before the terminal activation etc. This experiment was supposed to address that.
Unfortunately, the solution was not ideal. We attempt to run the activation script in a "sandbox" like mode and extract the environment changes. These changes however are acquired for the default terminal shell. This is where the problem starts. We now have to merge these changes with all the other shell environment variables. It does not do it right, sometimes it is not possible to do it right. It can also sometimes cause a problem where terminals get stuck in "reactivating" mode.
We are working on a different approach. This is the tracking issue for fixing the problem: microsoft/vscode-python#24699