Make `activate` et al. export custom prompt prefix as an envvar

[jwodder]

What's the problem this feature will solve?

I use a custom script (and I'm sure many others have similar scripts as well) for setting my prompt in Bash. It shows the name of the current virtualenv (if any) by querying the VIRTUAL_ENV environment variable, but if the virtualenv was created with a custom --prompt, it is unable to use this prompt prefix, as the activate script does not make this information available.

Describe the solution you'd like

The activate et al. scripts should set and export an environment variable named something like VIRTUAL_ENV_PROMPT_PREFIX that contains the prompt prefix (either custom or default) that virtualenv would prepend to the prompt. Ideally, this should be set even when VIRTUAL_ENV_DISABLE_PROMPT is set in case the user wants total control over their prompt.

[gaborbernat]

I'd be interested what core (venv) things about it, can you please create a ticket to https://bugs.python.org/

[jwodder]

@gaborbernat Ticket created: https://bugs.python.org/issue45264

[Tadaboody]

While no environment variable is created there is a $VIRTUAL_ENV/pyvenv.cfg file created with the prompt attribute. You can see an example usage in https://github.com/starship/starship/pull/1747/files#diff-6a82ae9de73a3d1ea14bd519050b16337b03b9022d8d5dcc5e95db7c08f9db28R120

[MegaBluejay]

Since 2020 venv does indeed set the VIRTUAL_ENV_PROMPT envar on activation: commit

[jimporter]

@gaborbernat Ticket created: https://bugs.python.org/issue45264

I filed a PR against this issue (GH version of the issue) which ensures that VIRTUAL_ENV_PROMPT gets exported no matter the value of VIRTUAL_ENV_DISABLE_PROMPT. Once that PR is resolved (either by merging or closing), I'll file a PR for this repo to sync the behavior with the built-in venv package.

[jimporter]

@gaborbernat I think we can close this issue now? Thanks for merging!