Python venv、pyvenv、pyenv、virtualenv、virtualenvwrapper、pipenv 等有什么区别？

What is the difference between venv, pyvenv, pyenv, virtualenv, virtualenvwrapper, pipenv, etc?

提问by Flimm

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?

Python 3.3 在其标准库中包含了新包venv. 它有什么作用，它与似乎与 regex 匹配的所有其他软件包(py)?(v|virtual|pip)?env有何不同？

回答by Flimm

PyPI packages not in the standard library:

PyPI 包不在标准库中：

• 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 the PATHenvironment variable to prefix it with a custom bindirectory (eg: env/bin/). An exact copy of the pythonor python3binary 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 using pip.

• pyenvis used to isolate Python versions. For example, you may want to test your code against Python 2.7, 3.6, 3.7 and 3.8, so you'll need a way to switch between them. Once activated, it prefixes the PATHenvironment 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 the PYENV_VERSIONenvironment variable, or the .python-versionfile, or the ~/.pyenv/versionfile. pyenvalso makes the process of downloading and installing multiple Python versions easier, using the command pyenv install.

• pyenv-virtualenvis a plugin for pyenvby the same author as pyenv, to allow you to use pyenvand virtualenvat the same time conveniently. However, if you're using Python 3.3 or later, pyenv-virtualenvwill try to run python -m venvif it is available, instead of virtualenv. You can use virtualenvand pyenvtogether without pyenv-virtualenv, if you don't want the convenience features.

• virtualenvwrapperis a set of extensions to virtualenv(see docs). It gives you commands like mkvirtualenv, lssitepackages, and especially workonfor switching between different virtualenvdirectories. This tool is especially useful if you want multiple virtualenvdirectories.

• pyenv-virtualenvwrapperis a plugin for pyenvby the same author as pyenv, to conveniently integrate virtualenvwrapperinto pyenv.

• pipenvaims to combine Pipfile, pipand virtualenvinto one command on the command-line. The virtualenvdirectory typically gets placed in ~/.local/share/virtualenvs/XXX, with XXXbeing a hash of the path of the project directory. This is different from virtualenv, where the directory is typically in the current working directory. pipenvis meant to be used when developing Python applications (as opposed to libraries). There are alternatives to pipenv, such as poetry, which I won't list here since this question is only about the packages that are similarly named.

• virtualenv是一个非常流行的工具，可以为 Python 库创建隔离的 Python 环境。如果您不熟悉这个工具，我强烈建议您学习它，因为它是一个非常有用的工具，我将在本答案的其余部分与它进行比较。

  它的工作原理是在一个目录（例如：）中安装一堆文件env/，然后修改PATH环境变量以使用自定义bin目录（例如：）作为前缀env/bin/。python或python3二进制文件的精确副本放置在此目录中，但 Python 被编程为首先在环境目录中查找与其路径相关的库。它不是 Python 标准库的一部分，但受到 PyPA（Python Packaging Authority）的正式祝福。激活后，您可以使用pip.

• pyenv用于隔离 Python 版本。例如，您可能想要针对 Python 2.7、3.6、3.7 和 3.8 测试您的代码，因此您需要一种在它们之间切换的方法。激活后，它会在PATH环境变量前面加上 前缀~/.pyenv/shims，其中有与 Python 命令 ( python, pip)匹配的特殊文件。这些不是 Python 提供的命令的副本；它们是特殊的脚本，可以根据PYENV_VERSION环境变量、.python-version文件或~/.pyenv/version文件动态决定运行哪个版本的 Python 。pyenv使用命令pyenv install.

• pyenv-virtualenv是一个插件pyenv由同一作者的pyenv，允许你使用pyenv和virtualenv在同一时间方便。但是，如果您使用的是 Python 3.3 或更高版本，pyenv-virtualenv则会尝试运行（python -m venv如果可用），而不是virtualenv. 如果您不想要便利功能，则可以不使用virtualenv和pyenv一起使用pyenv-virtualenv。

• virtualenvwrapper是一组扩展virtualenv（参见文档）。它为您提供了诸如mkvirtualenv、lssitepackages、 之类的命令，尤其是workon用于在不同virtualenv目录之间切换的命令。如果您需要多个virtualenv目录，此工具特别有用。

• pyenv-virtualenvwrapper是pyenv同一个作者的插件pyenv，为了方便地集成virtualenvwrapper到pyenv.

• pipenv旨在将Pipfile,pip和组合virtualenv成命令行上的一个命令。该virtualenv目录通常放置在 中~/.local/share/virtualenvs/XXX，它XXX是项目目录路径的散列。这不同于virtualenv，其中目录通常位于当前工作目录中。pipenv旨在用于开发 Python 应用程序（而不是库）。有替代pipenv，例如poetry，我不会在这里列出，因为这个问题仅与名称相似的包有关。

Standard library:

标准库：

• pyvenvis a script shipped with Python 3 but deprecated in Python 3.6as it had problems (not to mention the confusing name). In Python 3.6+, the exact equivalent is python3 -m venv.

• venvis a package shipped with Python 3, which you can run using python3 -m venv(although for some reason some distros separate it out into a separate distro package, such as python3-venvon Ubuntu/Debian). It serves the same purpose as virtualenv, but only has a subset of its features (see a comparison here). virtualenvcontinues to be more popular than venv, especially since the former supports both Python 2 and 3.

• pyvenv是 Python 3 附带的脚本，但在 Python 3.6 中已弃用，因为它有问题（更不用说令人困惑的名称）。在 Python 3.6+ 中，完全等效的是python3 -m venv.

• venv是 Python 3 附带的一个包，您可以使用它运行python3 -m venv（尽管出于某种原因，一些发行版将其分离为一个单独的发行版包，例如python3-venv在 Ubuntu/Debian 上）。它的用途与 相同virtualenv，但只有其功能的一个子集（请参阅此处的比较）。virtualenv继续比 更受欢迎venv，尤其是因为前者同时支持 Python 2 和 3。

Recommendation for beginners:

给初学者的建议：

This is my personal recommendation for beginners: start by learning virtualenvand pip, tools which work with both Python 2 and 3 and in a variety of situations, and pick up other tools once you start needing them.

这是我对初学者的个人建议：从学习virtualenv和开始pip，可以在 Python 2 和 3 以及各种情况下使用的工具，并在您开始需要它们时选择其他工具。

回答by Riaz Rizvi

I would just avoid the use of virtualenvafter Python3.3+ and instead use the standard shipped library venv. To create a new virtual environment you would type:

我只是避免virtualenv在 Python3.3+ 之后使用，而是使用标准的附带库venv。要创建一个新的虚拟环境，您可以输入：

$ python3 -m venv <MYVENV>  

virtualenvtries 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:

virtualenv尝试将 Python 二进制文件复制到虚拟环境的 bin 目录中。但是，它不会更新嵌入到该二进制文件中的库文件链接，因此如果您将 Python 从源代码构建到具有相对路径名的非系统目录中，则 Python 二进制文件会中断。由于这是您制作可分发 Python 副本的方式，因此这是一个很大的缺陷。顺便说一句，检查 OS X 上的嵌入式库文件链接，使用otool. 例如，在您的虚拟环境中，键入：

$ 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 virtualenvwrapperand pipenv. pyvenvis deprecated. pyenvseems to be used often where virtualenvis used but I would stay away from it also since I think venvalso does what pyenvis built for.

因此我会避免virtualenvwrapper和pipenv。pyvenv已弃用。pyenv似乎经常在使用的地方virtualenv使用，但我也会远离它，因为我认为它也venv可以pyenv用于构建。

venvcreates virtual environments in the shell that are freshand sandboxed, with user-installable libraries, and it's multi-python safe. Freshbecause virtual environments only start with the standard libraries that ship with python, you have to install any other libraries all over again with pip installwhile the virtual environment is active. Sandboxedbecause 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 librariesbecause the virtual environment's target folder is created without sudoin some directory you already own, so you won't need sudopermissions 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.

venv在 shell 中创建新的和沙盒的虚拟环境，具有用户可安装的库，并且它是多 python 安全的。新鲜，因为虚拟环境仅从 Python 附带的标准库开始，您必须pip install在虚拟环境处于活动状态时重新安装任何其他库。沙盒是因为这些新的库安装在虚拟环境之外是不可见的，所以你可以删除整个环境并重新开始，而不必担心影响你的基本 python 安装。用户可安装的库，因为创建虚拟环境的目标文件夹时没有sudo在您已经拥有的某些目录中，因此您不需要sudo权限即可将库安装到其中。最后它是多 python 安全的，因为当虚拟环境激活时，shell 只能看到用于构建该虚拟环境的 python 版本（3.4、3.5 等）。

pyenvis similar to venvin that it lets you manage multiple python environments. However with pyenvyou can't conveniently rollback library installs to some start state and you will likely need adminprivileges at some point to update libraries. So I think it is also best to use venv.

pyenv类似于venv它可以让您管理多个 python 环境。但是，pyenv您无法方便地将库安装回滚到某个启动状态，并且您可能admin在某些时候需要特权来更新库。所以我认为最好也使用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.

在过去的几年里，我在构建系统（emacs 包、python 独立应用程序构建器、安装程序……）中发现了许多问题，最终归结为virtualenv. 我认为当我们消除这个附加选项并只使用venv.

回答by F1Linux

I've went down the pipenvrabbit hole (it's a deep and dark hole indeed...) and since the last answer is over 2 years ago, felt it was useful to update the discussion with the latest developments on the Python virtual envelopes topic I've found.

我已经进入了pipenv兔子洞（它确实是一个又深又黑的洞......）并且由于最后一个答案是在 2 年前，我觉得用 Python 虚拟信封主题的最新发展更新讨论很有用我找到了

DISCLAIMER:

免责声明：

This answer is NOTabout continuing the raging debate about the merits of pipenvversusvenvas envelope solutions- I make no endorsement of either. It's about PyPAendorsing conflicting standards and how future development of virtualenvpromises to negate making an either/orchoice between them at all. I focused on these two tools precisely because they are the anointed ones by PyPA.

这个答案是不是对继续有关的优点的激烈争论pipenv与VENV如信封解决方案-我并没有任代言。这是关于PyPA认可相互冲突的标准，以及virtualenv 的未来发展如何承诺完全否定在它们之间做出非此即彼的选择。我之所以专注于这两个工具，正是因为它们是PyPA 的恩膏。

venv

venv

As the OP notes, venvis a tool for virtualizing environments. NOTa third party solution, but native tool. PyPAendorses venvfor creating VIRTUAL ENVELOPES: "Changed in version 3.5: The use of venv is now recommended for creating virtual environments".

正如 OP 所指出的，venv是一种用于虚拟化环境的工具。不是第三方解决方案，而是本机工具。PyPA支持venv来创建虚拟环境：“在 3.5 版中更改：现在建议使用 venv 来创建虚拟环境”。

pipenv

管道

pipenv- like venv- can be used to create virtual envelopes but additionally rolls-in package management and vulnerability checkingfunctionality. Instead of using requirements.txt, pipenvdelivers package management via Pipfile. As PyPAendorses pipenv for PACKAGE MANAGEMENT, that would seem to imply pipfileis to supplant requirements.txt.

pipenv- 与venv类似- 可用于创建虚拟信封，但另外还包含包管理和漏洞检查功能。而不是使用requirements.txt，pipenv通过Pipfile提供包管理。由于PyPA支持 pipenv 用于PACKAGE MANAGEMENT，这似乎意味着pipfile要取代requirements.txt.

HOWEVER: pipenvuses virtualenvas its tool for creating virtual envelopes, NOTvenvwhich is endorsed by PyPAas the go-to tool for creating virtual envelopes.

然而：pipenv使用virtualenv作为其创建虚拟信封的工具，而不是venv，它被PyPA认可为创建虚拟信封的首选工具。

Conflicting Standards:

冲突标准：

So if settling on a virtual envelope solution wasn't difficult enough, we now have PyPAendorsing two different tools which use different virtual envelope solutions. The raging Github debate on venv vs virtualenvwhich highlights this conflict can be found here.

因此，如果确定虚拟信封解决方案还不够困难，我们现在让PyPA认可两种使用不同虚拟信封解决方案的不同工具。Github 上关于venv 与 virtualenv的激烈争论突出了这种冲突，可以在这里找到。

Conflict Resolution:

解决冲突：

The Github debate referenced in above link has steered virtualenvdevelopment in the direction of accommodating venvin future releases:

上面链接中引用的 Github 辩论将virtualenv 的开发导向了在未来版本中适应venv的方向：

prefer built-in venv: if the target python has venv we'll create the environment using that (and then perform subsequent operations on that to facilitate other guarantees we offer)

更喜欢内置 venv：如果目标 python 有 venv，我们将使用它创建环境（然后对其执行后续操作以促进我们提供的其他保证）

Conclusion:

结论：

So it looks like there will be some future convergence between the two rival virtual envelope solutions, but as of now pipenv- which uses virtualenv- varies materially from venv.

因此，看起来这两个竞争对手的虚拟信封解决方案之间未来会有一些融合，但截至目前，使用的pipenvvirtualenv与venv.

Given the problems pipenvsolvesand the fact that PyPAhas given its blessing, it appearsto have a bright future. And if virtualenvdelivers on its proposed development objectives, choosing a virtual envelope solution should no longer be a case of either pipenvOR venv.

考虑到pipenv解决的问题以及PyPA的祝福，它似乎有着光明的未来。如果virtualenv 实现了其提议的开发目标，则选择虚拟信封解决方案不再是pipenv或venv 的情况。

回答by Arnuld

April 2020 Update

2020 年 4 月更新

I was searching for same when I came across this post. I think this issue of what tool to use is quite confusing and difficult for new Python users like me. This is directly from PyPA website regarding pipenv:

当我遇到这篇文章时，我正在寻找相同的内容。我认为这个使用什么工具的问题对于像我这样的 Python 新用户来说是相当混乱和困难的。这是直接来自 PyPA 网站关于 pipenv：

While this tutorial covers the pipenv project as a tool that focuses primarily on the needs of Python application development rather than Python library development, the project itself is currently working through several process and maintenance issues that are preventing bug fixes and new features from being published (with the entirety of 2019 passing without a new release). This means that in the near term, pipenv still suffers from several quirks and performance problems without a clear timeline for resolution of those isses.

While this remains the case, project maintainers are likely to want to investigate Other Tools for Application Dependency Management for use instead of, or together with, pipenv.

Assuming the April 2020 pipenv release goes ahead as planned, and the release after that also remains on track, then this caveat on the tutorial will be removed. If those releases don't remain on track, then the tutorial itself will be removed, and replaced with a discussion page on the available dependency management options.

虽然本教程将 pipenv 项目作为主要关注 Python 应用程序开发需求而非 Python 库开发需求的工具进行介绍，但该项目本身目前正在解决一些阻止错误修复和新功能发布的流程和维护问题（整个 2019 年都没有发布新版本）。这意味着在短期内，pipenv 仍然存在一些怪癖和性能问题，但没有明确的时间表来解决这些问题。

虽然情况仍然如此，但项目维护人员可能希望研究用于应用程序依赖性管理的其他工具，以代替 pipenv 或与 pipenv 一起使用。

假设 2020 年 4 月的 pipenv 版本按计划进行，之后的版本也保持正常，那么教程中的这个警告将被删除。如果这些版本没有保持在正轨上，那么教程本身将被删除，取而代之的是关于可用依赖项管理选项的讨论页面。