Repository navigation
Modify Python: Create Terminal to create an activated terminal even when automatic terminal activation is turned off #21864
Description
For a developer that only uses Python for a part of their project, the fact that we always activate Python in the terminal may not be ideal, which is one of the reasons for turning auto activation off (Set "python.terminal.activateEnvironment": false).
However they could still want to access an activated terminal when they do need it, which is when Python: Create Terminal could come in.
cc/ Logan Ramos (@lramos15) SteVen Batten (@sbatten) Feel free to edit it accordingly
Activity
github-actions commentedon Aug 22, 2023
Thanks for the feature request! We are going to give the community 60 days from when this issue was created to provide 7 👍 upvotes on the opening comment to gauge general interest in this idea. If there's enough upvotes then we will consider this feature request in our future planning. If there's unfortunately not enough upvotes then we will close this issue.
karrtikr commentedon Aug 22, 2023
One issue to note here is that, with our new way of activation (using environment variables), we may not be able to guarantee that selected environment is activated in a specific Python terminal (As shell init scripts may override what we set when creating the terminal).
So we'll have to either:
[-]Modify `Python: Create Terminal` to create an activated terminal even when automatic terminal activation turned off [/-][+]Modify `Python: Create Terminal` to create an activated terminal even when automatic terminal activation is turned off [/+]mkoohafkan commentedon Aug 23, 2023
I've been experimenting with ways to avoid the whole PowerShell ExecutionPolicy issue as I don't want to have all terminals activate Conda (as
conda init powershelldoes) and users don't necessarily have permissions to change their PowerShell ExecutionPolicy anyway. I've found that adding the following argument list to my default PowerShellalong with a custom config variable
"python.condaHome" : "path/to/conda"allows me to add Conda to the path so that environments can be activated. The BETTER approach would be to add those PowerShell arguments to the "Python" terminal only, but I haven't found a way to do that. I was originally thinking that the solution is for "Python" terminal to have its own profile (#21730) or have a mechanism to pass arguments to the "Python" terminal specifically, but if the "Python" terminal still attempted activation even whenpython.terminal.activateEnvironment": falsethen I could keep those arguments in the default profile and the Conda calls just wouldn't happen on a standard terminal.At this point I don't understand what the difference is between the "Python" terminal and the default terminal, they seem to behave exactly the same.
karrtikr commentedon Aug 24, 2023
Michael Koohafkan (@mkoohafkan) Try out #11039 (comment), which uses our new way of activation where we need not execute any scripts in terminal and instead use environment variables to activate the env.
david-waterworth commentedon Aug 25, 2023
I’d really like to see this implemented. I’m currently working on a project that contains a venv that I use to run a model training script, and a bash script that builds a model-repository which amongst other things requires creating and activating a cond and env using conda-pack (so must be run in a standard bash shell)
It’s really frustrating that despite “Terminal > Create Terminal” shows a “bash” icon and “F1 > Python Terminal” shows “python” the venv activation behaviour is now identical (ie a venv is always activated or never activated based on ‘ python.terminal.activateEnvironment’
This seems to be new behaviour and it’s very annoying when you need a bash terminal but it’s sourcing the last venv activated (in some cases from a totally different project). I keep having to manually deactivate in order to test the conda bash script.
so I now have to disable virtualenv activation completely in order to use vscode reliably
karrtikr commentedon Aug 28, 2023
David Waterworth (@david-waterworth) Feel free to open a new issue regarding this and we'll happy to look into it. #21825 seems to suggest a similar thing, we've mentioned potential workarounds for it there.
mkoohafkan commentedon Aug 29, 2023
Kartik Raj (@karrtikr) I was not able to get this working but perhaps I am missing a step. I'll wait for the official release and look for documentation then. Would like to see this current feature implemented anyway!
mkoohafkan commentedon Sep 12, 2023
karrtikr commentedon Sep 12, 2023
cesaryuan commentedon Sep 21, 2023
karrtikr commentedon Sep 21, 2023
brettcannon commentedon Nov 9, 2023
Thank you to everyone who upvoted this issue! Since the community showed interest in this feature request we will leave this issue open as something to consider implementing at some point in the future.
We do encourage people to continue 👍 the first/opening comment as it helps us prioritize our work based on what the community seems to want the most.
eleanorjboyd commentedon Dec 8, 2025
this is now something handled by the python environments extension- I will have to go through and understand the current behavior and desired behavior with this command given the switch.