Python 3.3 includes in its standard library the new package venv. What does it do, and how does it differ from all the other packages that seem to match the regex (py)?(v|virtual|pip)?env?
可以将文章内容翻译成中文,广告屏蔽插件可能会导致该功能失效(如失效，请关闭广告屏蔽插件后再试):
问题:
回答1:
PyPI packages not in the standard library:
virtualenvis a very popular tool that creates isolated Python environments for Python libraries. If you're not familiar with this tool, I highly recommend learning it, as it is a very useful tool, and I'll be making comparisons to it for the rest of this answer.It works by installing a bunch of files in a directory (eg:
env/), and then modifying thePATHenvironment variable to prefix it with a custombindirectory (eg:env/bin/). An exact copy of thepythonorpython3binary is placed in this directory, but Python is programmed to look for libraries relative to its path first, in the environment directory. It's not part of Python's standard library, but is officially blessed by the PyPA (Python Packaging Authority). Once activated, you can install packages in the virtual environment usingpip.pyenvis used to isolate Python versions. For example, you may want to test your code against Python 2.6, 2.7, 3.3, 3.4 and 3.5, so you'll need a way to switch between them. Once activated, it prefixes thePATHenvironment variable with~/.pyenv/shims, where there are special files matching the Python commands (python,pip). These are not copies of the Python-shipped commands; they are special scripts that decide on the fly which version of Python to run based on thePYENV_VERSIONenvironment variable, or the.python-versionfile, or the~/.pyenv/versionfile.pyenvalso makes the process of downloading and installing multiple Python versions easier, using the commandpyenv install.pyenv-virtualenvis a plugin forpyenvby the same author aspyenv, to allow you to usepyenvandvirtualenvat the same time conveniently. However, if you're using Python 3.3 or later,pyenv-virtualenvwill try to runpython -m venvif it is available, instead ofvirtualenv. You can usevirtualenvandpyenvtogether withoutpyenv-virtualenv, if you don't want the convenience features.virtualenvwrapperis a set of extensions tovirtualenv(see docs). It gives you commands likemkvirtualenv,lssitepackages, and especiallyworkonfor switching between differentvirtualenvdirectories. This tool is especially useful if you want multiplevirtualenvdirectories.pyenv-virtualenvwrapperis a plugin forpyenvby the same author aspyenv, to conveniently integratevirtualenvwrapperintopyenv.pipenv, by Kenneth Reitz (the author ofrequests), is the newest project in this list. It aims to combine Pipfile, pip and virtualenv into one command on the command-line.
Standard library:
pyvenvis a script shipped with Python 3 but deprecated in Python 3.6 as it had problems (not to mention the confusing name). In Python 3.6+, the exact equivalent ispython3 -m venv.venvis a package shipped with Python 3, which you can run usingpython3 -m venv(although for some reason some distros separate it out into a separate distro package, such aspython3-venvon Ubuntu/Debian). It serves a similar purpose tovirtualenv, and works in a very similar way, but it doesn't need to copy Python binaries around (except on Windows). Use this if you don't need to support Python 2. At the time of writing, the Python community seems to be happy withvirtualenvand I haven't heard much talk ofvenv.
回答2:
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 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.