Customize Virtualenv Prompt

[jplindquist]

I've been combing through docs and code for a while now, and see that it is possible to customize the virtualenv prompt by setting virtualenvs.prompt, an I would like it to be as simple/short as possible for my case (just using {project_name}), but when attempting to do so, the virtualenv prompt is consistently set to the full path of the project. Is this something I'm doing wrong, or is there a way to do this? I don't know if it matters, but in this case I'm just using poetry for dependency manage (package-mode = false).

❯ poetry config --list
cache-dir = "/Users/jlindquist/Library/Caches/pypoetry"
data-dir = "/Users/jlindquist/Library/Application Support/pypoetry"
installer.max-workers = null
installer.no-binary = null
installer.only-binary = null
installer.parallel = true
installer.re-resolve = true
keyring.enabled = true
python.installation-dir = "{data-dir}/python"  # /Users/jlindquist/Library/Application Support/pypoetry/python
requests.max-retries = 0
solver.lazy-wheel = true
system-git-client = false
virtualenvs.create = true
virtualenvs.in-project = true
virtualenvs.options.always-copy = false
virtualenvs.options.no-pip = false
virtualenvs.options.system-site-packages = false
virtualenvs.path = "{cache-dir}/virtualenvs"  # /Users/jlindquist/Library/Caches/pypoetry/virtualenvs
virtualenvs.prompt = "{project_name}"

After running poetry install I end up with the following venv.cfg that has prompt set to a full path vs. what is specified

cat .venv/pyvenv.cfg
home = /Users/jlindquist/mise/installs/python/3.13.3/bin
implementation = CPython
version_info = 3.13.3.final.0
virtualenv = 20.30.0
include-system-site-packages = false
base-prefix = /Users/jlindquist/mise/installs/python/3.13.3
base-exec-prefix = /Users/jlindquist/mise/installs/python/3.13.3
base-executable = /Users/jlindquist/mise/installs/python/3.13.3/bin/python3.13
prompt = /Users/jlindquist/dev/site24x7client/site24x7client

If I leave the default, or set the prompt to {project_name} + anything else, it works as expected, e.g.

poetry config virtualenvs.prompt
{project_name}-custom

❯ cat .venv/pyvenv.cfg
home = /Users/jlindquist/mise/installs/python/3.13.3/bin
implementation = CPython
version_info = 3.13.3.final.0
virtualenv = 20.30.0
include-system-site-packages = false
base-prefix = /Users/jlindquist/mise/installs/python/3.13.3
base-exec-prefix = /Users/jlindquist/mise/installs/python/3.13.3
base-executable = /Users/jlindquist/mise/installs/python/3.13.3/bin/python3.13
prompt = site24x7client-custom

[ungaaaabungaaa]

The virtualenv = 20.30.0 line is a useful clue. That version's configuration writer treats any value that matches an existing file or directory as a path. If your project contains a site24x7client directory, the prompt site24x7client is converted to its absolute path. site24x7client-custom stays unchanged when no file/directory has that name. This explains the difference in your two examples without requiring package-mode = false to be the cause.

The relevant old code is in PyEnvCfg.write() at 20.30.0. Upstream has since merged virtualenv #3366, which limits path conversion to configuration keys that actually contain paths.

I checked the 20.30.0 writer directly in a temporary directory containing site24x7client: it wrote an absolute path for that prompt, but preserved site24x7client-custom. The current source contains the path-key restriction, but I have not tested a complete updated Poetry environment.

So the next step is to update the virtualenv used by Poetry itself, using the installation method that manages Poetry. Updating virtualenv inside the application environment does not necessarily update Poetry's own dependency. You can keep:

virtualenvs.prompt = "{project_name}"

in Poetry's configuration (poetry.toml for local configuration), or set it with:

poetry config --local virtualenvs.prompt '{project_name}'

An existing .venv retains its generated configuration; changing the setting/updating the tool does not rewrite it. Verify with a fresh disposable project/environment first, then recreate your real environment from its project/lock files when appropriate. Your -custom suffix is also a workaround for the old writer, provided that string does not match a local path.

This is a verified explanation of the old writer; I did not reproduce your complete original Poetry/mise setup.

AI assistance: written with OpenAI Codex; the old-writer checks were run locally.