Trying to come up with a default directory name for virtual environments

brettcannon · March 21, 2020, 3:58am

The question

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.

My answer

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 .venv:

github.com

python-poetry/poetry/blob/master/poetry/utils/env.py#L216-L221


is_root_venv = self._poetry.config.get("virtualenvs.in-project")
# If we are required to create the virtual environment in the root folder,
# create or recreate it if needed
if is_root_venv:
    create = False
    venv = self._poetry.file.parent / ".venv"

So it seems tools have chosen .venv. I’m also a fan as well because:

It doesn’t clash with .env files.
It’s hidden by default as it’s almost an implementation detail and not part of your workspace.
Tools like ripgrep will ignore it.

Other ideas

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)?