Modify Python: Create Terminal to create an activated terminal even when automatic terminal activation is turned off

[karrtikr]

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.

#1387 (comment)

cc/ @lramos15 @sbatten Feel free to edit it accordingly

[github-actions]

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]

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:

• Continue sending commands for "Python" terminals.
• Or add a feature in VS Code to apply env variables after shell init scripts are run, in which case it could be some work to support this reliably.

[mkoohafkan]

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 powershell does) 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 PowerShell

"args": ["-ExecutionPolicy",  "ByPass", "-NoExit", "-Command",  "& '${config:python.condaHome}\\shell\\condabin\\conda-hook.ps1' "]

along 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 when python.terminal.activateEnvironment": false then 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]

@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]

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]

when you need a bash terminal but it’s sourcing the last venv activated (in some cases from a totally different project).

@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]

@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.

@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!

[brettcannon]

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.