`.venv` can be: 1. A directory that is a virtual environment (i.e. `pyvenv.cfg` file in the directory); can be a symlink 2. A file with an absolute path to a directory containing a virtual environment # Why a `.venv` directory? It's used as the default location by: 1. The Python extension for VS Code 2. uv 3. The Python Launcher for Unix It's also one of the most common directory names used for virtual environments (based on a Twitter poll I ran once; post has been subsequently deleted). # Why a `.venv` file? I call this the "Simon Willison feature", but it's for those that either can't or explicitly do not want the virtual environment in their project directory. In Simon's case it's because they code in a Dropbox-backed directory initially, and so they don't want the virtual environment backed up. For others it could be because they want to store virtual environments in a global location and can't use a symlink (e.g. Windows users). Using the same name as the directory avoids ambiguity about precedence. # What about a directory of virtual environments? I have previously thought about supporting a directory containing multiple virtual environments. In that instance you would want to know the Python version, type of interpreter used, and some naming scheme for why the virtual environment exists. But the only time this comes up is for tools like Nox, Tox, and Hatch who want to manage the virtual environments anyway. As such, having them write out a `.venv` symlink/file takes care of having a default virtual environment to use while letting them manage the environments however they choose.