gh-111501: venv: do not export PS1 in activate

[rpigott]

PS1 is a global parameter. It does not need (and should not be) exported to the users environment.

• Issue: PS1 is exported when a virtual environment is activated #111501

[bedevere-bot]

Most changes to Python require a NEWS entry.

Please add it using the blurb_it web app or the blurb command-line tool.

[ghost]

All commit authors signed the Contributor License Agreement.

[bedevere-bot]

Most changes to Python require a NEWS entry.

Please add it using the blurb_it web app or the blurb command-line tool.

[vsajip]

Is there some discussion somewhere about this? What problem is being solved here?

[rpigott]

Not recently that I'm aware, but a quick look turns up [1].

Exporting PS1 isn't really relevant to venv's purpose, and it is incorrect in the case that a different subshell is started, since prompt expansion differs between shells. The only sense in exporting something is if you mean for processes to inherit the value, and PS1 is a parameter special to current interactive shell. For example, in zsh my PS1 is currently:

$ print $PS1
%F{cyan}[%~% ]%(?.%F{green}.%F{red})%B%(!.#.$)%b%f 

Obviously, that isn't meaningful to a bash shell. Personally I notice this when starting zsh -f which is similar to bash --norc, since the prompt of the parent shell is unintentionally preserved, even after calling deactivate.

[1] https://unix.stackexchange.com/questions/247585/to-export-or-not-to-export-bash-ps1-variable

---

TBH, I think there is an even better argument to be made that the PS1 modifications should be dropped altogether. It's strangely invasive and really unnecessary since VIRTUAL_ENV is already set and exported.

An interested user could surely just include VIRTUAL_ENV in PS1 in a way that expands to nothing if it is unset. Or, if they prefer, include it only in zsh's RPROMPT, or include it only in the terminal window title, or include it somewhere in the middle of their normal prompt, add colors, etc.... Not to mention that the current method preculdes modifying the prompt persistently in any way while a venv is active, since PS1 will be completely overwritten again when the venv is deactivated. You can always craft some prompt modifying functions that the user can slap in postactivate if they want the original behavior back, or just place them in postactivate by default if you don't want to be disruptive.

[vsajip]

I'm more worried about backward compatibility when considering changes in this area. It's been like this for a long time (and AFAIK virtualenv does this too) and no-one has really brought it up before. I certainly don't want to deal with any support work if the behaviour change affects existing users. Note that activate isn't really needed to use a venv - it's more of a convenience thing.

[romkatv]

#111501 explains why exporting PS1 is incorrect.

[rpigott]

Updated to resolve conflicts.

[michaelmaitland]

Kindly pinging

[github-actions]

This PR is stale because it has been open for 30 days with no activity.

[gaborbernat]

You're right on the facts: it's been there since the original PEP 405 activate (2012), virtualenv mirrors it, and this is the first report. None of those bear on correctness — romkatv's issue body is the why, with the typeset -p PS1 repro (declare -x appears after activate) and the broken bash prompt under zsh -f.

On compatibility: removing the export changes exactly one observable thing — PS1 no longer enters the child environment. The shell that sourced activate is unaffected (assignment alone drives its prompt), and deactivate restores as before. The only thing a child loses is a prompt that was already wrong for it and lingered past deactivate, so there's nothing dependable to preserve.

On "virtualenv does this too": agreed, and it's the same bug there — I've opened pypa/virtualenv#3158 to remove it on that side in parallel so the two stay aligned. For the record, bash is the only CPython activator that exports its prompt variable (activate.csh uses set prompt, fish/ps1 use functions).

[FFY00]

I agree with the rationale described.