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

这是我对初学者的个人建议：首先学习 virtualenv 和 pip，这两种工具都适用于 Python 2 和 3 并适用于各种情况，并在开始后学习其他工具需要他们。

现在回答这个问题：这些类似命名的事物之间有什么区别：venv、virtualenv 等？

PyPI 包不在标准库中：

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 使下载和安装多个 Python 版本的过程更容易。

pyenv-virtualenv 是一个与pyenv 同一作者的pyenv 插件，让您可以方便地同时使用pyenv 和virtualenv。但是，如果您使用的是 Python 3.3 或更高版本，pyenv-virtualenv 将尝试运行 python -m venv（如果可用），而不是 virtualenv。如果您不想要便利功能，您可以在没有 pyenv-virtualenv 的情况下一起使用 virtualenv 和 pyenv。

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

pyenv-virtualenvwrapper 是一个与pyenv 同一作者的pyenv 插件，用于方便地将virtualenvwrapper 集成到pyenv 中。

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

标准库：

pyvenv（不要与上一节中的 pyenv 混淆）是 Python 3.3 到 3.7 附带的脚本。它从 Python 3.8 中删除，因为它有问题（更不用说令人困惑的名称）。运行 python3 -m venv 和 pyvenv 效果完全一样。

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

---

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

$ python3 -m venv <MYVENV>  

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)

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

venv 在外壳中创建新鲜和沙盒的虚拟环境，带有用户可安装的库，它是多python安全。

新鲜：因为虚拟环境仅从 python 附带的标准库开始，所以在虚拟环境处于活动状态时，您必须使用 pip install 重新安装任何其他库。

沙盒：因为这些新库安装在虚拟环境之外都不可见，所以您可以删除整个环境并重新开始，而不必担心影响您的基本 python 安装。

用户可安装的库：因为在您已经拥有的某个目录中创建的虚拟环境的目标文件夹没有 sudo，因此您不需要 sudo 权限即可将库安装到其中。

多 python 安全：因为当虚拟环境激活时，shell 只能看到用于构建该虚拟环境的 python 版本（3.4、3.5 等）。

pyenv 与 venv 的相似之处在于它允许您管理多个 Python 环境。但是，使用 pyenv 您不能方便地将库安装回滚到某个启动状态，并且您可能在某些时候需要 admin 权限来更新库。所以我认为最好使用venv。

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

编辑：BDFL 的推文，

我使用 venv（在标准库中）和一堆 shell 别名来快速切换。 — Guido van Rossum (@gvanrossum) 2020 年 10 月 22 日

---

更新 20200825：

在“结论”段落下方添加

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

免责声明：

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

venv

正如 OP 所述，venv 是一种用于虚拟化环境的工具。 不是第三方解决方案，而是原生工具。 PyPA 支持 venv 创建虚拟信封：“Changed in version 3.5: The use of venv is now recommended for creating virtual environments”。

管道

pipenv - 与 venv 类似 - 可用于创建虚拟信封，但还可用于包管理和{1 } 功能。 pipenv 通过 Pipfile 提供包管理，而不是使用 requirements.txt。作为 PyPA endorses pipenv for PACKAGE MANAGEMENT，这似乎意味着 pipfile 将取代 requirements.txt。

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

冲突标准：

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

解决冲突：

上述链接中引用的 Github 辩论已将 virtualenv 的开发导向future releases中适应 venv 的方向：

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

结论：

因此，看起来这两种竞争的虚拟信封解决方案未来会出现一些融合，但截至目前 pipenv（使用 virtualenv）与 venv 存在重大差异.

鉴于 the problems pipenv solves 以及 PyPA 给予了它的祝福这一事实，它似乎拥有光明的未来。如果 virtualenv 实现了其提议的开发目标，那么选择虚拟信封解决方案不应再成为 pipenv em> 或 venv。

更新 20200825：

我在进行此分析时看到的对 Pipeenv 的反复批评是它没有得到积极的维护。确实，使用一个由于缺乏持续开发而未来可能会受到质疑的解决方案有什么意义呢？在经历了大约 18 个月的枯竭期后，Pipenv 再次被积极开发。事实上，从那时起，released 就已经进行了大量的重大更新。

---

让我们从这些工具想要解决的问题开始：

我的系统包管理器没有我想要的 Python 版本，或者我想并排安装多个 Python 版本，Python 3.9.0 和 Python 3.9.1、Python 3.5.3 等

然后使用 pyenv。

我想安装和运行具有不同的、相互冲突的依赖项的多个应用程序。

然后使用 virtualenv 或 venv。这些几乎是完全可以互换的，不同之处在于 virtualenv 支持较旧的 python 版本并具有一些更小的独特功能，而 venv 在标准库中。

我正在开发 /application/ 并且需要管理我的依赖项，并管理我的项目依赖项的依赖项解析。

然后使用 pipenv 或诗歌。

我正在开发 /library/ 或 /package/ 并希望指定我的库用户需要安装的依赖项

然后使用设置工具。

我使用了 virtualenv，但我不喜欢 virtualenv 文件夹分散在各种项目文件夹中。我想要集中管理环境和一些简单的项目管理

然后使用 virtualenvwrapper。变体：pyenv-virtualenvwrapper 如果你也使用 pyenv。

不建议

pyvenv。这已弃用，请改用 venv 或 virtualenv。不要与 pipenv 或 pyenv 混淆。

---

2020 年 1 月更新

@Flimm 很好地解释了所有差异。通常，我们想知道所有工具之间的区别，因为我们想决定什么最适合我们。那么，下一个问题是：使用哪一个？我建议您选择以下两种官方方式之一来管理虚拟环境：

Python Packaging 现在推荐 Pipenv

Python.org 现在推荐 venv

---

pyenv - 管理不同的 python 版本，

所有其他人-创建虚拟环境（具有隔离的python版本并安装了“要求”），

pipenv 想要结合所有，除了以前它安装“要求”（进入活动的虚拟环境，或者如果没有活动则创建自己的）

所以也许你只会对 pipenv 感到满意。

但我使用：pyenv + pyenv-virtualenvwrapper，+ pipenv（仅用于安装要求的 pipenv）。

在 Debian 中：

apt install libffi-dev install pyenv 基于 https://www.tecmint.com/pyenv-install-and-manage-multiple-python-versions-in-linux/，但是.. .. 但不是 pyenv-virtualenv install pyenv-virtualenvwrapper（可以是独立库或 pyenv 插件，这里是第二个选项）： $ pyenv install 3.9.0 $ git clone https://github.com/pyenv/pyenv-virtualenvwrapper.git $(pyenv root)/plugins /pyenv-virtualenvwrapper # 在 ~/.bashrc 添加： # export $VIRTUALENVWRAPPER_PYTHON="/usr/bin/python3" $ source ~/.bashrc $ pyenv virtualenvwrapper

然后为您的项目创建虚拟环境（workingdir 必须存在）：

pyenv local 3.9.0  # to prevent 'interpreter not found' in mkvirtualenv
python -m pip install --upgrade pip setuptools wheel
mkvirtualenv <venvname> -p python3.9 -a <workingdir>

并在项目之间切换：

workon <venvname>
python -m pip install --upgrade pip setuptools wheel pipenv

在一个项目中，我有文件 requirements.txt，没有修复里面的版本（如果不需要某些版本限制）。您有 2 个可能的工具可以将它们安装到当前虚拟环境中：pip-tools 或 pipenv。假设您将使用 pipenv：

pipenv install -r requirements.txt

这将创建 Pipfile 和 Pipfile.lock 文件，固定版本在第二个。如果您想在完全相同版本的地方重新安装，那么（Pipfile.lock 必须存在）：

pipenv install

请记住，Pipfile.lock 与某些 Python 版本相关，如果您使用其他版本，则需要重新创建。

如您所见，我编写了 requirements.txt。这有一些问题：您也必须从 Pipfile 中删除已删除的包。所以直接写Pipfile可能会更好。

所以你可以看到我对 pipenv 的使用非常糟糕。也许如果你用得好，它可以代替一切？

EDIT 2021.01：我已将堆栈更改为：pyenv + pyenv-virtualenvwrapper + poetry。 IE。我不使用 apt 或 pip 安装 virtualenv 或 virtualenvwrapper，而是安装 pyenv 的插件 pyenv-virtualenvwrapper。这是更简单的方法。

Poetry 对我来说很棒：

poetry add <package>   # install single package
poetry remove <package>
poetry install   # if you remove poetry.lock poetry will re-calculate versions

---

作为一个 Python 新手，这个问题让我无休止地沮丧，让我困惑了几个月。当我知道我将在未来几年使用它时，我应该投资学习哪个虚拟环境和包管理器？

回答这个令人烦恼的问题的最佳文章是 Jake Vanderplas 的 https://jakevdp.github.io/blog/2016/08/25/conda-myths-and-misconceptions/。尽管已有几年历史，但它提供了实用的答案以及 Python 包和虚拟环境管理器在这些最先进技术的发展过程中的历史。

在数据科学和“大数据云计算”社区中，我尤其感到沮丧，因为 conda 被广泛用作 Python 和 JavaScript、SQL、Java、HTML5 和 Jupyter Notebooks 的虚拟环境管理器和全功能包管理器。

那么，当 conda 完成 pip 和 venv 变体所做的一切时，为什么还要使用 pip 呢？

答案是，“因为如果 conda 包根本不可用，您必须使用 pip。”很多时候，所需的包仅以 pip 格式提供，没有简单的解决方案，只能使用 pip。您可以学习使用 conda build，但如果您不是包维护者，则必须说服包所有者为每个新版本生成一个 conda 包（或自己做）。

这些基于 pip 的软件包在许多重要和实用的方面有所不同：

稳定

到期

复杂

积极支持（相对于死亡或死亡）

Python 生态系统“核心”与“边缘”（即集成到 Python.org 发行版）附近的采用水平

易于理解和使用（适合初学者）

我将从包成熟度和稳定性的维度回答你关于两个包的问题。

venv 和 virtualenv 是最成熟、最稳定、最受社区支持的。从在线文档中，您可以看到 virtualenv 截至今天的版本为 20.x。 virtualenv

virtualenv 是一个创建隔离 Python 环境的工具。从 Python 3.3 开始，它的一个子集被集成到标准库的 venv 模块下。 venv 模块不提供这个库的所有功能，仅举几个更突出的例子：速度较慢（由于没有 app-data 种子方法），不可扩展，无法为任意安装的 python 版本创建虚拟环境（和自动发现这些），不能通过 pip 升级，没有丰富的编程 API（描述虚拟环境而不创建它们）。

virtualenvwrapper 是一组帮助人们使用 virtualenv 的脚本（它是一个维护不善的“包装器”，它的最后一次更新是在 2019 年。virtualenvwrapper

我的建议是尽可能避免使用所有 pip 虚拟环境。改用 conda。 Conda 提供了一种统一的方法。它由专业的开源开发人员团队维护，并有一家信誉良好的公司提供资金和商业支持的版本。相比之下，维护 pip、venv、virtualenv、pipenv 和许多其他 pip 变体的团队资源有限。 pip 虚拟环境的多样性对于初学者来说是令人沮丧的。基于 pip 的虚拟环境工具的复杂性、碎片化、边缘和不受支持的包以及极其不一致的支持促使我使用 conda。对于数据科学工作，我的建议是在 conda 包不存在时使用基于 pip 的虚拟环境管理器作为最后的手段。

venv 变体之间的差异仍然让我感到害怕，因为我学习新软件包的时间有限。 pipenv、venv、pyvenv、pyenv、virtualenv、virtualenvwrapper、诗歌和其他有几十个差异和复杂性，需要几天时间才能理解。我讨厌走上一条路，当维护者辞职（或太忙而无法维护它）时，对一个包的支持就会崩溃。我只需要完成我的工作。

本着乐于助人的精神，这里有一些链接可以帮助您深入了解，但不要迷失在但丁的地狱（re：pip）中。

A Guide to Python’s Virtual Environments

选择“核心”Python 包来投资你的职业（长期），而不是短期完成工作）很重要。但是，这是一个业务分析问题。您是想简单地完成一项任务，还是一个专业的软件工程师构建可扩展的高性能系统，随着时间的推移需要最少的维护工作？恕我直言，conda 比处理 pip-plurality 问题更容易将您带到后者。 conda 仍然缺少 1 步 pip-package 迁移工具，这使得这成为一个没有实际意义的问题。如果我们可以简单地将 pip 包转换为 conda 包，那么 pypi.org 和 conda-forge 可以合并。 Pip 是必要的，因为 conda 包（还）不是通用的。许多 Python 程序员要么懒得创建 conda 包，要么只用 Python 编程，不需要 conda 的语言无关/多语言支持。

conda 对我来说是天赐之物，因为它支持云软件工程和数据科学对 JavaScript、SQL 和 Jupyter Notebook 扩展的多语言支持的需求，并且 conda 在 Docker 和其他云原生环境中运行良好。我鼓励您学习和掌握 conda，这将使您能够回避许多基于 pip 的工具可能永远无法回答的复杂问题。

把事情简单化！我需要一个包来完成我需要的 90% 的工作，并为剩下的 10% 的边缘情况提供指导和解决方法。

查看此处链接的文章，了解有关基于 pip 的虚拟环境的更多信息。

我希望这对原始海报有所帮助，并为 pip 和 conda 爱好者提供一些思考的东西。

---