Repository navigation
Spike: Investigate approach to use environment variables for environment activation #20492
Description
Activity
Multiroot scenarios:
Each workspace can have a different environment selected. How to decide which one applies to the collection? Options:
-
Active editor decides the Python which appears in the status bar:
Every time active editor changes, the environment collection is updated to contain fresh environment variables.
Problems:- Prompt shows up asking to relaunch the terminal:
- Terminal cwd also dictates which environment is to be activated. For eg. in the following case the second workspace is not using julia but the julia is activated in the terminal for second workspace:
- Prompt shows up asking to relaunch the terminal:
-
Active terminal decides which Python to activate using environment collection:
If cwd of first workspace is active, the environment of first workspace is applied.Problems:
- User try opening the Python file from the second workspace and runs it, it ends up running in the activated environment of the first workspace:
- User try opening the Python file from the second workspace and runs it, it ends up running in the activated environment of the first workspace:
Potential requests from VSCode:
In the second case, if
envoption interminal.createTerminalAPI overrides the environment set by collection, we can use the right environment. The prompt to relaunch terminal is also not expected to show in this case.To make the first case work would require a more convoluted solution from VSCode, for eg. environment collection only applies to a particular workspace.
For simplicity it would also work if we could disable prompts altogether in multiroot workspaces:
-
Kartik Raj (@karrtikr) am I understanding this right that the environment variable collection is applied to the workspace, not the individual folder in the workspace? Would allowing to apply a particular workspace to the
EnvironmentVariableMutatorsolve that issue?The idea of
envoverriding seems like a scary breaking change.am I understanding this right that the environment variable collection is applied to the workspace, not the individual folder in the workspace?
Yes
Would allowing to apply a particular workspace to the EnvironmentVariableMutator solve that issue?
I assume you also mean existing APIs like
replace,appendetc. will have to be extended to be workspace folder specific as well, to indicate which workspace folder the changes are applied to. If so then yes this would be great.Fish shell scenario:
Fish shell does not have a prompt variable which we could set like cmd to indicate which environment is active:
Potential requests from VSCode:
-
One idea is to use the
terminal.titleproperty to indicate the environment is activated: Allow to provide description to environment collection API vscode#171108 -
Another idea could be to use shell integration script to insert an environment variable which could influence the prompt, inspiration taken from official
activate.fishscript:code --locate-shell-integration-path fishIf the above script is amended to support something similar to:
functions -c fish_prompt _old_fish_prompt # With the original prompt function renamed, we can override with our own. function fish_prompt # Save the return status of the last command. set -l old_status $status # Output the venv prompt; color taken from the blue of the Python logo. printf "%s%s%s" (set_color 4B8BBE) "$VSCODE_PS1 " (set_color normal) # Restore the return status of the previous command. echo "exit $old_status" | . # Output the original/"old" prompt. _old_fish_prompt end
Variable names would have to unique enough, but this way we can directly edit the
VSCODE_PS1variable to influence the prompt.
-
Debugger scenario:
We provide a way to debug a python file using its own debugger python that maybe different than what is currently selected:
However the collection is activated using the selected environment, so when debugging the file the incorrect activated shell is used (
juliais selected environment):
Solution:
Add
envproperty to send environment variables of the debugger python environment:
This is passed down using
RunInTerminalRequestto VSCode, so the user code is debugged using the expected environment variables. The downside is that if the terminal remains after the debug session completes, user might try to interact with it, and be confused because the shell therein is incorectly activated.-
Potential VSCode request:
One solution could be to for VSCode to use the env provided by
RunInTerminalRequestto also apply to thePython Debug consoleterminal that remains after debugging is done, instead of just using it to debug user code. Variables can be set when spawning the shell itself, but it is expected to override environment collection in this case. -
Treat terminal as single use:
In this approach, the lifetime of the shell in the terminal is tied to the lifetime of the debug session. We can use “wait on exit” debugger feature, which causes the debug session to present a “Press any key to continue…” prompt at the end, and session is not considered terminated until the prompt is answered.
-
I assume you also mean existing APIs like replace, append etc. will have to be extended to be workspace folder specific as well, to indicate which workspace folder the changes are applied to. If so then yes this would be great.
The trick would be coming up with a way to do it in a backwards compatible way so we don't break the API. Haven't thought about it too much but for example:
export interface EnvironmentVariableMutator { readonly type: EnvironmentVariableMutatorType; readonly value: string; readonly workspace: Workspace | undefined; } export interface EnvironmentVariableCollection extends Iterable<[variable: string, mutator: EnvironmentVariableMutator]> { replace(variable: string, value: string, workspace?: Workspace): void; append(variable: string, value: string, workspace?: Workspace): void; prepend(variable: string, value: string, workspace?: Workspace): void; }
Tracked in microsoft/vscode#171173
Reacted by Kartik RajOne idea is to use the terminal.title property to indicate the environment is activated: microsoft/vscode#171108
What if we allowed an extension to control a variable that is fed into both the title and description settings?
Tracked in microsoft/vscode#171175
Seems reasonable to me, we can come back to it based on user feedback if need be:
Created action item based on spike: #20822
- locked as resolved and limited conversation to collaborators
on Apr 9, 2023
For #11039
Getting activated environment variables from conda
Get activated environment variables for each shell.
conda initalready but powershell might not be.Diff is another option. Can we use diff for cmd in powershell, and add the prompt variable ourselves?
Use environment variable collection to activate terminals
Blockers: microsoft/vscode#99878 on macOS
pythonconfig scenarioAlso there are some meaningless changes: like
trueto1.Instead of this would it make more sense to user to just say: Terminal needed to be restarted to apply results of
<conda command>: Allow to provide description to environment collection API vscode#171108Some other alternatives:
What about multiroot workspaces?
Environment variable collection for a workspace?
Clarify what:
means.
Relaunch terminal doesn't show up always.
on did change default shell event? microsoft/vscode#160694 (comment)
onDidOpenTerminal and
vscode.env.shell: microsoft/vscode#171164python.terminal.activateinterminlsettings if we aren't sending commands.vscode.env.shellmight return empty string to extension if fetched very soon after startup vscode#160694 (comment)onDidChangeShellevent which is fired when default terminal profile changes vscode#171164 (comment)