Make setting PS1 optional in pythonTerminalEnvVarActivation experiment

[levrik]

My prompt already includes the activated virtual environment, so it would be great if setting PS1 could be made optional.

[levrik]

I actually found the following code in the .venv/bin/activate which was executed before:

if [ -z "${VIRTUAL_ENV_DISABLE_PROMPT-}" ] ; then
    _OLD_VIRTUAL_PS1="${PS1-}"
    if [ "xstudio-py3.9" != x ] ; then
        PS1="(studio-py3.9) ${PS1-}"
    else
        PS1="(`basename \"$VIRTUAL_ENV\"`) ${PS1-}"
    fi
    export PS1
fi

I figured that VIRTUAL_ENV_DISABLE_PROMPT is set to 1 for me. This seems to be automatically set by my prompt (starship.rs) as it already appends the activated environment by itself.

I guess that VS Code simply also has to respect this env variable and not modify PS1 if it's set.

[karrtikr]

We use .venv/bin/activate to figure out what variables to set in terminal, one of which it returns us is the PS1.

This seems to be automatically set by my prompt (starship.rs) as it already appends the activated environment by itself.

I assume this happens in one of the shell initialization scripts (.bashrc). Unfortunately Python extension does not have access to that yet, so we cannot tell whether VIRTUAL_ENV_DISABLE_PROMPT is set at terminal level. Can you try setting it at system level at /etc/environment? Add the following:

VIRTUAL_ENV_DISABLE_PROMPT=1

[levrik]

@karrtikr I guess the extra prompt wasn't showing up before as .venv/bin/activate was executed after the shell was initialized? In my .zshrc I'm executing eval "$(starship init zsh)" which indeed does VIRTUAL_ENV_DISABLE_PROMPT=1 internally.

/etc/environment seems to be a Linux-only thing and doesn't work on macOS. Setting this variable under ~/.zprofile has the effect of (.venv) to be prepended to the prompt instead of (studio-py3.9). So it seems to be respected when added to this file but doesn't have the desired effect? Same result when adding it to ~/.zshenv instead of ~/.zprofile.

[karrtikr]

I guess the extra prompt wasn't showing up before as .venv/bin/activate was executed after the shell was initialized?

Yep, so the script had the context of .zshrc which we don't have with the experiment.

Unfortunately it has to be done system wide in order for all of VS Code to pick it up, so none of the terminal profile specific scripts would help. Try this answer: https://stackoverflow.com/a/588442, make sure to reboot system after setting var.

[levrik]

@karrtikr TBH this sounds quite excessive. I got quite excited about this experiment as the command injection often interfered with other scripts like oh-my-zsh update when opening the terminal. I'll disable it for now again and hope that a solution can be found before this gets released to everyone. Either automatic or through a manual configuration.

[karrtikr]

Another option could be to launch VS Code via code . from zsh terminal itself.

Other than that, manually configuring /etc/launchd.conf to add setenv VIRTUAL_ENV_DISABLE_PROMPT 1, followed by a restart seems to be only option right now.

[karrtikr]

With microsoft/vscode#145234 we're hoping to have the context of terminal variables as well, which is when this issue should go away automatically 🙂 Closing as limitation for now.

[levrik]

@karrtikr Okay. I'll keep an eye on that other ticket then and try to work around it for now.

[karrtikr]

Thanks! Appreciate the early feedback

[karrtikr]

@levrik FYI in pre-release version of extension, adding the following .env in workspace root:

VIRTUAL_ENV_DISABLE_PROMPT=1

should also work.

[levrik]

Thanks for the hint. This actually works. After checking the output of the Python extension I realized that it actually contains env variables Starship (my prompt) sets.

It sets VIRTUAL_ENV_DISABLE_PROMPT to 1 here: https://github.com/starship/starship/blob/43b2d42cd526e34c5f0290e7409fbd6d3a54e908/src/init/starship.zsh#L88

When putting an export in front of this line, it actually works out-of-the-box without .env. I don't know how the extension fetches the environment variables so I wonder if this is an oversight on this extension's side or on Starship's side.

[karrtikr]

Oh, that's interesting. I'm wondering that maybe exporting a variable sets it for the system? Will look into it. (Thanks for the hint 😉)