Python 3.3 在其标准库中包含了新包venv
. 它有什么作用,它与似乎与正则表达式匹配的所有其他软件包有何不同(py)?(v|virtual|pip)?env
?
7 回答
这是我对初学者的个人建议:从学习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
文件或文件即时决定运行哪个版本的 Python~/.pyenv/version
。pyenv
还可以使用命令来简化下载和安装多个 Python 版本的过程pyenv install
。pyenv-virtualenv
pyenv
是同作者的一个插件pyenv
,让你在使用pyenv
的virtualenv
同时又方便。但是,如果您使用的是 Python 3.3 或更高版本,pyenv-virtualenv
将尝试运行python -m venv
(如果可用),而不是virtualenv
. 如果您不想要便利功能,您可以在没有的情况下使用virtualenv
and 。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
,我不会在这里列出,因为这个问题只是关于名称相似的包。
标准库:
pyvenv
(不要与上一节混淆pyenv
)是 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。
我只是避免使用virtualenv
after Python3.3+ 而是使用标准发布的 library 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
and 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
.
编辑:BDFL 的推文,
我使用 venv(在标准库中)和一堆 shell 别名来快速切换。
— Guido van Rossum (@gvanrossum) 2020 年 10 月 22 日
更新 20200825:
在“结论”段落下方添加
我已经进入了pipenv
兔子洞(这确实是一个又深又黑的洞......),因为最后一个答案是 2 年前,我觉得用 Python 虚拟信封主题的最新发展来更新讨论很有用已经找到了。
免责声明:
这个答案不是关于继续关于pipenv 与 venv作为信封解决方案的优点的激烈辩论 -我不认可任何一个。这是关于PyPA认可相互冲突的标准,以及virtualenv的未来发展如何承诺完全否定在它们之间做出非此即彼的选择。我专注于这两个工具正是因为它们是PyPA 指定的工具。
venv
正如 OP 所指出的,venv是一种用于虚拟化环境的工具。不是第三方解决方案,而是原生工具。PyPA认可venv用于创建虚拟信封:“在 3.5 版中更改:现在建议使用 venv 来创建虚拟环境”。
管道
pipenv - 与venv类似- 可用于创建虚拟信封,但另外还包含包管理和漏洞检查功能。代替使用requirements.txt
,通过Pipfilepipenv
提供包管理。由于PyPA认可 pipenv 用于PACKAGE MANAGEMENT,这似乎意味着要取代。pipfile
requirements.txt
但是:pipenv使用virtualenv作为创建虚拟信封的工具,而不是 venv,它被PyPA认可为创建虚拟信封的首选工具。
冲突标准:
因此,如果确定虚拟信封解决方案还不够困难,我们现在有PyPA支持两种使用不同虚拟信封解决方案的不同工具。可以在这里找到关于venv 与 virtualenv的激烈争论,突出了这种冲突。
解决冲突:
上述链接中引用的 Github 辩论引导virtualenv开发朝着在未来版本中适应venv的方向发展:
更喜欢内置 venv:如果目标 python 有 venv,我们将使用它创建环境(然后对其执行后续操作以促进我们提供的其他保证)
结论:
因此,看起来这两种竞争的虚拟信封解决方案之间将会有一些未来的融合,但截至目前,使用的pipenvvirtualenv
与venv
.
鉴于pipenv解决的问题以及PyPA的支持,它似乎有一个光明的未来。如果virtualenv实现了它提出的开发目标,那么选择虚拟信封解决方案应该不再是pipenv或venv的情况。
更新 20200825:
在进行此分析时,我经常看到对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。
不建议
- pyvenv。这已弃用,请改用 venv 或 virtualenv。不要与 pipenv 或 pyenv 混淆。
- pyenv - 管理不同的 python 版本,
- 所有其他人-创建虚拟环境(具有隔离的python版本并安装了“要求”),
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。我不使用 apt 或 pip 安装 virtualenv 或 virtualenvwrapper,而是安装pyenv
's plugin 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 是一个创建隔离 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 爱好者提供一些思考的东西。