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
{{ message }}
Repository navigation
VS Code auto-activating python virtual environment, but not auto-updating PowerShell prompt correctly with (.venv) prefix as expected #22723
Using latest VS Code with Python extension installed
Have Python file selected (.py or .ipynb) and correct interpreter selected [e.g. Python 3.11.2 ('.venv':venv) ]
When I open the terminal (default is Powershell), the virtual environment is correctly activated. Can confirm via pip -V or Get-Command python which shows it's pointing to the correct .venv path
However, PowerShell prompt prefix is not updated to show virtual environment is activated (so confusing at 1st glance)
If I activate manually via .\.venv\Scripts\Activate.ps1 is get the correct prompt prefix (.venv) PS C:\dev\arm_sandbox>
Have confirmed I've set permissive Execution policy for scripts in PowerShell to Unrestricted
... any ideas on what might be the issue? If I switch to running VS Code in an Ubuntu/WSL session it works as expected.
Please read this. But be careful as this feature seems to have glitches at moment, so you may end up with a non-activated environment, even with alerts and documentation saying otherwise. I'm about to open a new issue about that.
Anyway, your issue should still be considered, as having a (base) prefix when the activated environment is another one is itself a bug.
What was wrong with the old way? This new change feels like a regression. It hurts the majority of users for a feature(s) only a small minority will use. When i open a terminal i expect it to activate the venv and show the venv prefix.
I don't know the details of this new implementation, but the old way was a bit hacky to my taste. You could see the commands being typed on the terminal, and sometimes the activation command would scramble over other commands.
But I agree that the new implementation is not working properly. At very least, an option to do things the old way should have been provided.
Thanks for the link to the prior discussions as they didn't readily show up after much searching. Didn't know about mousing over the terminal tab to see details on virtual environment which is nice.
Would still like to see the prompt get updated w/venv at some point... to quote Tim Peters, 'Explicit is better than implicit.'
same situation on unbuntu22 with zsh. The last version of this extension is working fine. I don't want to set auto_activate_base to false. I need it when I use terminal independently.
Thanks all for reporting and providing the pointers, as you suspect this is a known behavior, but we're restricted by a technical limitation which prevents us from showing (.venv) prompt for Powershell.
so you may end up with a non-activated environment, even with alerts and documentation saying otherwise. I'm about to open a new issue about that.
ubalklen I'm interested in this, I noticed you haven't gotten the chance to open an issue yet. We would be happy to take a look.
EeyoreLee (@EeyoreLee) We're working on a fix here which avoids the issue for zsh, given shell integration is enabled: #22850. You can subscribe to #22774 for further updates but we hope to make a pre-release in a day or two.
Activity
ubalklen commentedon Jan 9, 2024
Please read this. But be careful as this feature seems to have glitches at moment, so you may end up with a non-activated environment, even with alerts and documentation saying otherwise. I'm about to open a new issue about that.
Anyway, your issue should still be considered, as having a
(base)prefix when the activated environment is another one is itself a bug.JustinOstrowsky commentedon Jan 9, 2024
What was wrong with the old way? This new change feels like a regression. It hurts the majority of users for a feature(s) only a small minority will use. When i open a terminal i expect it to activate the venv and show the venv prefix.
ubalklen commentedon Jan 9, 2024
Justin Ostrowsky (@JustinOstrowsky) take a look at #11039.
I don't know the details of this new implementation, but the old way was a bit hacky to my taste. You could see the commands being typed on the terminal, and sometimes the activation command would scramble over other commands.
But I agree that the new implementation is not working properly. At very least, an option to do things the old way should have been provided.
scott-straka commentedon Jan 9, 2024
Thanks for the link to the prior discussions as they didn't readily show up after much searching. Didn't know about mousing over the terminal tab to see details on virtual environment which is nice.
Would still like to see the prompt get updated w/venv at some point... to quote Tim Peters, 'Explicit is better than implicit.'
GTSeventeEn commentedon Jan 12, 2024
Use
conda config --set auto_activate_base False,help me solve the problem。this urlEeyoreLee commentedon Jan 30, 2024
same situation on unbuntu22 with zsh. The last version of this extension is working fine. I don't want to set auto_activate_base to false. I need it when I use terminal independently.
karrtikr commentedon Feb 5, 2024
Thanks all for reporting and providing the pointers, as you suspect this is a known behavior, but we're restricted by a technical limitation which prevents us from showing
(.venv)prompt for Powershell.ubalklen I'm interested in this, I noticed you haven't gotten the chance to open an issue yet. We would be happy to take a look.
EeyoreLee (@EeyoreLee) We're working on a fix here which avoids the issue for zsh, given shell integration is enabled: #22850. You can subscribe to #22774 for further updates but we hope to make a pre-release in a day or two.
karrtikr commentedon Feb 5, 2024
As for the main issue in hand, check out #22289, where we're considering providing an opt out for virtual environments.
ubalklen commentedon Feb 6, 2024
Kartik Raj (@karrtikr) there you go: #22856