New submission from Corey Seliger <co...@seligerfamily.org>: The venv module does not evenly create the necessary binaries/symlinks when building virtualenvs. If you call venv like this:
seliger@core:~/venvs$ python3 -m venv venvA seliger@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@core:~/venvs$ python3.5 -m venv venvB seliger@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 <rep...@bugs.python.org> <https://bugs.python.org/issue32444> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
