I would just avoid the use of virtualenv
after Python3.3+ and instead use the standard shipped library venv
. To create a new virtual environment you would type:
$ python3 -m venv <MYVENV>
virtualenv
tries to copy the Python binary into the virtual environment's bin directory. However it does not update library file links embedded into that binary, so if you build Python from source into a non-system directory with relative path names, the Python binary breaks. Since this is how you make a copy distributable Python, it is a big flaw. BTW to inspect embedded library file links on OS X, use otool
. For example from within your virtual environment, type:
$ otool -L bin/python
python:
@executable_path/../Python (compatibility version 3.4.0, current version 3.4.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.0.0)
Consequently I would avoid virtualenvwrapper
and pipenv
. pyvenv
is deprecated. pyenv
seems to be used often where virtualenv
is used but I would stay away from it also since I think venv
also does what pyenv
is built for.
venv
creates virtual environments in the shell that are fresh and sandboxed, with user-installable libraries, and it's multi-python safe. Fresh because virtual environments only start with the standard libraries that ship with python, you have to install any other libraries all over again with pip install
while the virtual environment is active. Sandboxed because none of these new library installs are visible outside the virtual environment, so you can delete the whole environment and start again without worrying about impacting your base python install. User-installable libraries because the virtual environment's target folder is created without sudo
in some directory you already own, so you won't need sudo
permissions to install libraries into it. Finally it is multi-python safe, since when virtual environments activate, the shell only sees the python version (3.4, 3.5 etc.) that was used to build that virtual environment.
pyenv
is similar to venv
in that it lets you manage multiple python environments. However with pyenv
you can't conveniently rollback library installs to some start state and you will likely need admin
privileges at some point to update libraries. So I think it is also best to use venv
.
In the last couple of years I have found many problems in build systems (emacs packages, python standalone application builders, installers...) that ultimately come down to issues with virtualenv
. I think python will be a better platform when we eliminate this additional option and only use venv
.
EDIT: Tweet of the BDFL,
I use venv (in the stdlib) and a bunch of shell aliases to quickly switch.— Guido van Rossum (@gvanrossum) October 22, 2020