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
Having .venv activated and then switching the environment in the environment manager to non-venv such as python3.13, does not seem to change the terminal state.
When I click the terminal icon next to my workspace name (after switching from venv to non-venv interpreter option), terminal is created with previously activated (now expected to be deactivated but wrongly persists as activated) venv.
In additional to deactivate&activate issues(such as #49) that I have previously created, perhaps shell environment API will also be a key in solving this.
The text was updated successfully, but these errors were encountered:
@anthonykim1 Do you have the python extension env variable experiment on? This extension explicitly activates by sending a command to the terminal. If you have the python extension experiment on, then it can lead to activations because the variables were already set.
anthonykim1
changed the title
Switching interpreter to global in environment manager does deactivate previously activated .venv
Switching interpreter to global in environment manager doesn't deactivate previously activated .venv
Dec 5, 2024
Good point, I definitely had the terminal env var experiment on and probably one or both of the mentioned setting on as well.
I should remember to turn off all three in future testing. Probably helpful to note it as some of them are defaulted to true and would be easier to track down issues that are only specific to env manager.
Testing microsoft/vscode-python#24503
Video example:
Screen.Recording.2024-12-03.at.12.50.40.PM.mov
Having .venv activated and then switching the environment in the environment manager to non-venv such as python3.13, does not seem to change the terminal state.
When I click the terminal icon next to my workspace name (after switching from venv to non-venv interpreter option), terminal is created with previously activated (now expected to be deactivated but wrongly persists as activated) venv.
In additional to deactivate&activate issues(such as #49) that I have previously created, perhaps shell environment API will also be a key in solving this.
The text was updated successfully, but these errors were encountered: