[英]What is the difference between venv, pyvenv, pyenv, virtualenv, virtualenvwrapper, pipenv, etc?
Python 3.3 在其标准库中包含了新的包venv
。 它有什么作用,它与匹配正则表达式(py)?(v|virtual|pip)?env
的所有其他包有何不同?
这是我对初学者的个人建议:从学习virtualenv
和pip
开始,这些工具可以在 Python 2 和 3 以及各种情况下使用,一旦你开始需要它们,就选择其他工具。
现在回答这个问题:这些类似命名的事物之间有什么区别:venv、virtualenv 等?
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
的一组扩展(参见docs )。 它为您提供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
,我不会在此处列出,因为这个问题仅与名称相似的包有关。
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
在 shell 中创建新的和沙盒的虚拟环境,带有用户可安装的库,并且它是多 python 安全的。
新鲜:因为虚拟环境仅从 python 附带的标准库开始,所以您必须在虚拟环境处于活动状态时使用pip install
重新安装任何其他库。
沙盒:因为这些新的库安装在虚拟环境之外都不可见,所以您可以删除整个环境并重新开始,而不必担心影响您的基本 python 安装。
用户可安装的库:因为虚拟环境的目标文件夹是在您已经拥有的某个目录中创建的而没有sudo
,因此您不需要sudo
权限即可将库安装到其中。
multi-python safe :因为当虚拟环境激活时,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 日
在“结论”段落下方添加
我已经进入了pipenv
兔子洞(它确实是一个又深又黑的洞...... )并且由于最后一个答案是 2 年前,我觉得用 Python 虚拟信封主题的最新发展来更新讨论很有用我找到了。
这个答案不是关于继续关于pipenv与venv作为信封解决方案的优点的激烈辩论 -我不认可任何一个。 这是关于PyPA认可相互冲突的标准,以及virtualenv的未来发展如何承诺完全否定在它们之间做出非此即彼的选择。 我专注于这两个工具正是因为它们是PyPA 指定的工具。
正如 OP 所指出的, venv是一种用于虚拟化环境的工具。 不是第三方解决方案,而是原生工具。 PyPA认可venv用于创建虚拟信封:“在 3.5 版中更改:现在建议使用 venv 来创建虚拟环境”。
pipenv - 与venv类似 - 可用于创建虚拟信封,但另外还包含包管理和漏洞检查功能。 pipenv不使用requirements.txt
,而是通过pipenv
提供包管理。 由于PyPA认可 pipenv 用于PACKAGE MANAGEMENT ,这似乎意味着pipfile
将取代requirements.txt
。
但是: pipenv使用virtualenv作为创建虚拟信封的工具,而不是venv ,它被PyPA认可为创建虚拟信封的首选工具。
因此,如果确定虚拟信封解决方案还不够困难,我们现在有PyPA支持两种使用不同虚拟信封解决方案的不同工具。 可以在这里找到关于venv 与 virtualenv的激烈争论,突出了这种冲突。
上述链接中引用的 Github 辩论引导virtualenv开发朝着在未来版本中适应venv的方向发展:
更喜欢内置 venv:如果目标 python 有 venv,我们将使用它创建环境(然后对其执行后续操作以促进我们提供的其他保证)
因此,看起来这两种竞争的虚拟信封解决方案之间将会有一些未来的融合,但到目前为止,使用virtualenv
的pipenv与venv
有很大的不同。
鉴于pipenv解决的问题以及PyPA的支持,它似乎有一个光明的未来。 如果virtualenv实现了它提出的开发目标,那么选择一个虚拟信封解决方案应该不再是pipenv或venv的情况。
在进行此分析时,我经常看到对Pipenv的反复批评是它没有得到积极的维护。 确实,使用一个由于缺乏持续开发而未来可能会受到质疑的解决方案有什么意义呢? 在经历了大约 18 个月的枯竭期后, Pipenv再次被积极开发。 事实上,自那以后已经发布了大量的重大更新。
让我们从这些工具想要解决的问题开始:
我的系统包管理器没有我想要的 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。
不建议
pipenv想要结合所有,除了以前它安装“需求”(进入活动的虚拟环境,如果没有活动则创建自己的)
所以也许你只会对 pipenv 感到满意。
但我使用:pyenv + pyenv-virtualenvwrapper,+ pipenv(仅用于安装要求的 pipenv)。
在 Debian 中:
apt install libffi-dev
根据https://www.tecmint.com/pyenv-install-and-manage-multiple-python-versions-in-linux/安装 pyenv,但是..
.. 但不是 pyenv-virtualenv 安装 pyenv-virtualenvwrapper (可以是独立库或 pyenv 插件,这里是第二个选项):
$ pyenv install 3.9.0 $ git clone https://github.com/pyenv/pyenv-virtualenvwrapper.git $(pyenv root)/plugins/pyenv-virtualenvwrapper # inside ~/.bashrc add: # 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 的使用非常糟糕。 也许如果你用得好,它可以代替一切?
编辑 2021.01 :我已将堆栈更改为: pyenv + pyenv-virtualenvwrapper + poetry
。 IE。 我不使用 virtualenv 或 virtualenvwrapper 的 apt 或 pip 安装,而是安装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 的软件包在许多重要和实用的方面有所不同:
我将从包成熟度和稳定性的维度回答你关于两个包的问题。
venv 和 virtualenv 是最成熟、最稳定、最受社区支持的。 从在线文档中,您可以看到 virtualenv 截至今天的版本为 20.x。 虚拟环境
virtualenv 是一个创建隔离 Python 环境的工具。 从 Python 3.3 开始,它的一个子集被集成到标准库的 venv 模块下。 venv 模块不提供这个库的所有特性,仅举几个比较突出的例子:
is slower (by not having the app-data seed method), is not as extendable, cannot create virtual environments for arbitrarily installed python versions (and automatically discover these), is not upgrade-able via pip, does not have as rich programmatic API (describe virtual environments without creating them).
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)中。
选择“核心”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 爱好者提供一些思考的东西。
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.