[New-bugs-announce] [issue32444] python -m venv has incongruous behavor creating binaries

[Corey Seliger]

New submission from Corey Seliger <corey at seligerfamily.org>:

The venv module does not evenly create the necessary binaries/symlinks when building virtualenvs. If you call venv like this:

seliger at core:~/venvs$ python3 -m venv venvA

seliger at core:~/venvs$ ls -l venvA/bin/
total 32
-rw-r--r-- 1 seliger seliger 2143 Dec 28 21:29 activate
-rw-r--r-- 1 seliger seliger 1259 Dec 28 21:29 activate.csh
-rw-r--r-- 1 seliger seliger 2397 Dec 28 21:29 activate.fish
-rwxrwxr-x 1 seliger seliger  254 Dec 28 21:29 easy_install
-rwxrwxr-x 1 seliger seliger  254 Dec 28 21:29 easy_install-3.5
-rwxrwxr-x 1 seliger seliger  226 Dec 28 21:29 pip
-rwxrwxr-x 1 seliger seliger  226 Dec 28 21:29 pip3
-rwxrwxr-x 1 seliger seliger  226 Dec 28 21:29 pip3.5
lrwxrwxrwx 1 seliger seliger    7 Dec 28 21:29 python -> python3
lrwxrwxrwx 1 seliger seliger   16 Dec 28 21:29 python3 -> /usr/bin/python3

...you do not end up with a "python3.5" binary. 

However, if you call venv like this:

seliger at core:~/venvs$ python3.5 -m venv venvB

seliger at core:~/venvs$ ls -l venvB/bin
total 32
-rw-r--r-- 1 seliger seliger 2143 Dec 28 21:29 activate
-rw-r--r-- 1 seliger seliger 1259 Dec 28 21:29 activate.csh
-rw-r--r-- 1 seliger seliger 2397 Dec 28 21:29 activate.fish
-rwxrwxr-x 1 seliger seliger  256 Dec 28 21:29 easy_install
-rwxrwxr-x 1 seliger seliger  256 Dec 28 21:29 easy_install-3.5
-rwxrwxr-x 1 seliger seliger  228 Dec 28 21:29 pip
-rwxrwxr-x 1 seliger seliger  228 Dec 28 21:29 pip3
-rwxrwxr-x 1 seliger seliger  228 Dec 28 21:29 pip3.5
lrwxrwxrwx 1 seliger seliger    9 Dec 28 21:29 python -> python3.5
lrwxrwxrwx 1 seliger seliger    9 Dec 28 21:29 python3 -> python3.5
lrwxrwxrwx 1 seliger seliger   18 Dec 28 21:29 python3.5 -> /usr/bin/python3.5

...you DO get the necessary python3.5 binary. Some vendors are making it a requirement to call a specific pythonX.Y binary to ensure compatibility. One such example is the serverless framework when deploying to Amazon Web Services. Another example is the useful pyenv utility that manages full Python builds and virtualenvs. When it depends upon venv, it exhibits the same behavior. I submitted a patch workaround to force calling venv using pythonX.Y, but this really seems like an issue with the venv module itself.

The expected behavior should be that venv generates all three binaries (python, python3, and python3.5) regardless of how the python command was invoked.

I am able to reproduce this on Python 3.5 and 3.6. I could not find any other similar references in searching the bug system.

----------
components: Library (Lib)
messages: 309157
nosy: seliger
priority: normal
severity: normal
status: open
title: python -m venv has incongruous behavor creating binaries
type: behavior
versions: Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32444>
_______________________________________