On Twitter I asked people for suggestions for an environment variable name to store the default/typical name they use for virtual environment directories:
That led to @uranusjr suggesting we should just choose a standard name for virtual environment directories:
Then @pradyunsg agreed:
And so here we are, with me kicking off a more formal discussion of what a standard name for virtual environments should be for tools that just want a default name for users.
Looking at tools that create virtual environments for people, pipenv uses
.venv. Poetry has a setting to create the virtual environment locally, but it isn’t specified where the directory ends up being. If you dig into the code it turns out to be
So it seems tools have chosen
.venv. I’m also a fan as well because:
- It doesn’t clash with
- It’s hidden by default as it’s almost an implementation detail and not part of your workspace.
- Tools like ripgrep will ignore it.
In my poll on this question the most people voted for
venv (although it wasn’t a majority). I think people prefer
venv instead of
.venv because they don’t like it being hidden while still being obvious what it is. I’ve also heard others suggest
__venv__ so they can ignore
__*__ in their
.gitignore files and get
__pycache__ ignoring for free (although that clashes with the
__app__ name used by Azure Functions so I have a work bias against that idea).
An enhnacement to the idea
@uranusjr also suggested supporting the idea of a
.venv file which pointed to a virtual environment directory:
It was also liked by @pradyunsg:
The idea is basically if
.venv is a file instead of a directory is a a one-line file which points to the directory of a virtual environment. I’m personally fine with this idea as it leads to some flexibility as @uranusjr points out:
The reason behind asking this
The entire reason I’m bringing this up is I would love to have the Python Launcher for UNIX automatically select an in-workspace virtual environment even if it isn’t activated. It already picks up an activated virtual environment, but in my typical dev workflow I have a
.venv directory with a virtual environment sitting there, so why even have to care about activation when I run
py? I obviously want that
.venv/bin/python so even have to do anything to select it? It’s the ultimate laziness factor in launching Python; I want two letter to just know what I intend.
But I’m also a lazy, time-constrained open source developer and don’t want to have to implement any logic to search for an appropriate virtual environment if there are multiple options. Plus I’m paranoid about a performance hit if I have to search a ton of directories. So I have been trying to think of a way to tell the Python Launcher “use this virtual environment”. But now @pradyunsg and @uranusjr have inspired me to simply simplify things and JFDI by choosing a name and stop worrying about fancy configuration options. Hence this post.
So does anyone have any arguments against going with
.venv as an informal community standard for naming a virtual environment (both a single one or a file pointing to a virtual environment)?