Most changes to Python require a NEWS entry.

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

All commit authors signed the Contributor License Agreement.

Most changes to Python require a NEWS entry.

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

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

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.

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.

#111501 explains why exporting PS1 is incorrect.

Updated to resolve conflicts.

Kindly pinging