Python and virtualenv - why is the python version used to name subdirectories?

Question

Why does the virtualenv creation mechanism insist on naming subdirectories with the version of Python used? I am referring to something like test_venv/venv3/lib/>>>python3.6<<</site-packages

When you're in a 3.6 venv, you of course get 3.6 packages. And same with 2.7 meaning 2.7 packages. And you can't use these without activate-ing the venv beforehand so the risk of confusion seems low.

Among other things people often have questions about why something is not working that have to do with either the OS system path or the python sys.path. And having those subpaths named after the python version makes it hard to generalize on where to find site-packages.

edit: the following is on macOS, but I got roughly the same behavior on an Ubuntu 18.04 VM.

create a python 2 virtual environment with `virtualenv ./venv2`

directory structure with tree -d -L 3 ./venv2/:

./venv2/
├── bin
├── include
│   └── python2.7 -> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7
└── lib
    └── python2.7
        ├── config -> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/config
        ├── distutils
        ├── encodings -> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/encodings
        ├── lib-dynload -> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload
        └── site-packages

create a python 3 virtual environment with `python3 -m venv ./venv3`

Slightly better, but still impacts site-packages.

./venv3/
├── bin
├── include
└── lib
    └── python3.6
        └── site-packages

Curiously, on Windows, the path is `ENV/Lib/site-packages`. However, the [documentation](https://virtualenv.pypa.io/en/stable/userguide/) does say `ENV/lib/pythonX.X/site-packages/`. Now I wonder why the inconsistency among different OS... — azalea, Mar 15 '19 at 22:15
@azalea that seems much better, which is why I am wondering why the macOS and Linux behave this way. — JL Peyret, Mar 15 '19 at 22:21
Not an answer to your question, but you can get the path of site-packages no matter where that is. see: https://stackoverflow.com/questions/122327/how-do-i-find-the-location-of-my-python-site-packages-directory#comment79362432_46071447 — azalea, Mar 15 '19 at 22:22

Ondrej K. · Accepted Answer · 2019-03-15T23:01:13.423

It is consistent with the specification:

Running this command creates the target directory... And it creates an (initially empty) lib/pythonX.Y/site-packages (or Lib\site-packages on Windows) subdirectory.

This is the cpython bit that implements it if you were curious.

As to why: it reflects (and as noted (and reflected in specification and code) different on Windows) behavior of how search paths are constructed from sys.prefix (which in turn would be determined from location of python executable in your venv in this case). Resolution thereof is implemented in Modules/getpath.c and also contains more detailed description in comments.

Long story short: It allows venv to relatively easily use existing code for all the search path handling work it needs.

score 1 · Answer 2 · answered Mar 15 '19 at 22:41

Because system can hos few version of python, then naming convention allows to distinguish site-package folders.

And it is easier to keep this naming convention in virtualenv than checking in code if python interpreter is started form virtualev or normal installation and then choose proper path.

Python and virtualenv - why is the python version used to name subdirectories?

create a python 2 virtual environment with virtualenv ./venv2

create a python 3 virtual environment with python3 -m venv ./venv3

2 Answers2

create a python 2 virtual environment with `virtualenv ./venv2`

create a python 3 virtual environment with `python3 -m venv ./venv3`