Use new vsc API to activate terminal without running any commands in terminal

[DonJayamanne]

Contribute to terminal environments

This new API allows extensions to change environment variables when the terminal is starting up.

• Support terminal activation for debugger without running Commands in terminal
• Running python in terminal will user correct environment even when terminal is already open
• Not polluting terminal history with unnecessary commands
• expose .env variables into terminal without activation of environment

const collection = window.getEnvironmentVariableCollection(true);
const separator = process.platform === 'win32' ? ';' : ':';
collection.prepend('PATH', `/foo${separator}`);
collection.replace('JAVA_HOME', '/bar');

[iutlu]

Hello, I was wondering if this would help with #5559 (specifically for conda environments)?

[luabud]

hey @iutlu! it is something we've been actively discussing in the team, but we need to do some investigations first

[Tyriar]

The API moved to ExtensionContext late last month and should be stable in 1.46.

[yumasheta]

Will this also set the $VIRTUAL_ENV envvar for Terminals started with an active (python or conda) venv in vscode?
Although not the main issue of #9374, I still did mention it there.

[luabud]

@yumasheta thanks for bringing this up! We haven't fully spec'ed this yet (I just updated the label here on the issue to reflect it 😊), so that's something to be considered.

[luabud]

https://code.visualstudio.com/updates/v1_46#_environment-variable-collection

[jwtanx]

This feature is great however, I would like to deactivate the self-activated venv sometimes to switch to another venv, sometimes. Is there any workaround to fix deactivate the venv?

(mix-3.10) user@Latitude:~/Desktop$ deactivate
deactivate: command not found
(mix-3.10) user@Latitude:~/Desktop$ 

The quick workaround for me now is by adding this into the settings.json but I feel there must be a better solution

    "python.terminal.activateEnvInCurrentTerminal": false,
    "python.terminal.activateEnvironment": true,
    "python.experiments.optOutFrom": ["pythonTerminalEnvVarActivation"],

[karrtikr]

Hi @jwtanx thanks for the feedback, please try out the workaround mentioned in #22037 (comment) for this issue.

[jwtanx]

Hi @jwtanx thanks for the feedback, please try out the workaround mentioned in #22037 (comment) for this issue.

Thanks!

[nikhilweee]

I'm a regular vscode-python user and the only reason I'm here is because I couldn't figure out how to deactivate the auto-activated environment. It's really nice to see the dev team working on improving the extension and I'm very welcoming of the features added in the past few releases, but please try not to break existing workflows.

[karrtikr]

Thanks for your continued supported and letting us know about this.

We want to reassure that we are committed to preserving existing workflows, but sometimes changes are necessary for improvements. In this case, the deactivate command's limitation is due to the new approach, and we've documented a workaround in a comment made just above #11039 (comment).

[brettcannon]

@nikhilweee do note that we are trying to fix existing workflows (sending the source command to the terminal was extremely brittle and failed constantly), and that sometimes requires us to (maybe) break other workflows. That being said, we are looking if there's a way to let you all keep the automatic activation we have come up with along with some deactivate command to help discover the workaround in #22037 (comment) or some other solution.

[Queuecumber]

My existing flow was broken by this change, it would be nice if there was a setting to re-enable the explicit source command. I can't see another workaround to fix it but I am open to trying some things.

Because of the way my server environment is setup I need to edit on a different machine than I launch my code on. To make this simpler I made a terminal like this:

"terminal.integrated.profiles.linux": {
        "login": {
            "path": "ssh",
            "args": [
                "<redacted hostname>",
                "-t",
                "cd ${workspaceFolder} && zsh"
            ]
        }
    },

this worked fine with the explicit source command but loses all the environment variables with the new method. I've tried a few things to set them such as adding ${env:PATH} before my zsh command and using the ssh argument -o SendEnv=PATH but nothing has worked so far.

[Tyriar]

@Queuecumber is there a reason you're not using Remote - SSH?

[Queuecumber]

I am -- I have to "remote - ssh" to the code editing server and then ssh to a code submission server to actually run it.

And to clarify a little more, I am not allowed to directly connect the vscode server to the code submission server, it has to be a bare ssh session.

[brettcannon]

My existing flow was broken by this change, it would be nice if there was a setting to re-enable the explicit source command.

Please upvote #22289 if you would like us to add such a setting.

[DonJayamanne]

@Tyriar From my recollection either the bashrc or bashprofile is not loaded by the terminals when using remote ssh.
Its possible thats whats going on here.

[Tyriar]

@Queuecumber unless I'm misunderstanding, it sounds like it was working before just by coincidence because the same file structure exists on your "code submission server"? In that case I would expect it not to be a supported scenario for the extension/feature.

[Queuecumber]

Not coincidence: design. It's the same filesystem (network filesystem) on both machines, otherwise I couldn't easily develop on one machine and submit code on the other.

We do this because the vscode server can use enough resources to slow down the machine and we don't want it interfering with code submissions.

There are two ways to fix it: ship the environment variables over ssh (this should be possible) or just have an option to use the old source based method (should be easy).

If you'd like more details on our setup and its motivation I'm happy to start a discussion though NVIDIA internal channels.