问题:venv,pyvenv,pyenv,virtualenv,virtualenvwrapper,pipenv等有什么区别?

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

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?


回答 0

PyPI软件包不在标准库中:

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

    它的工作方式是在目录(例如:)中安装一堆文件env/,然后修改PATH环境变量以在其之前添加自定义bin目录(例如:)env/bin/。在完全相同的副本pythonpython3二进制文件放在这个目录中,但是Python编程寻找相对于其路径优先库,环境中的目录。它不是Python标准库的一部分,但是受到PyPA(Python包装管理局)的正式认可。激活后,您可以使用在虚拟环境中安装软件包pip

  • 用于隔离Python版本。例如,您可能想针对Python 2.7、3.6、3.7和3.8测试代码,因此需要一种在它们之间切换的方法。一旦被激活,它的前缀PATH与环境变量~/.pyenv/shims,那里有专用的文件相匹配的Python命令(pythonpip)。这些不是Python附带命令的副本。它们是特殊的脚本,它们可以根据PYENV_VERSION环境变量,.python-version文件或~/.pyenv/version文件即时确定要运行哪个版本的Python 。pyenv使用命令,还可以简化下载和安装多个Python版本的过程pyenv install

  • 是一个插件pyenv由同一作者的pyenv,允许你使用pyenvvirtualenv在同一时间方便。但是,如果您使用的是Python 3.3或更高版本,请pyenv-virtualenv尝试运行python -m venv它(如果有),而不是virtualenv。如果您不希望使用便利功能,则可以在不使用的情况下一起使用virtualenv和。pyenvpyenv-virtualenv

  • virtualenv(参见docs)的一组扩展。它为您提供诸如mkvirtualenv,的命令,lssitepackages尤其是workon在不同virtualenv目录之间切换时。如果您需要多个virtualenv目录,此工具特别有用。

  • pyenv与作者相同的插件pyenv,可以方便地集成virtualenvwrapperpyenv

  • 旨在结合Pipfilepipvirtualenv为在命令行一个命令。该virtualenv目录通常放置在中~/.local/share/virtualenvs/XXXXXX是项目目录路径的哈希值。这与不同virtualenv,后者的目录通常位于当前工作目录中。pipenv是指在开发Python应用程序(而不是库)时使用。还有的替代品pipenv,例如poetry,我将不在此处列出,因为该问题仅与名称相似的软件包有关。

标准库:

  • 是Python 3附带的脚本,但由于存在问题(更不用说混乱的名称了)而在Python 3.6中不推荐使用。在Python 3.6及更高版本中,确切的等效项是python3 -m venv

  • 是Python 3附带的软件包,您可以使用它运行python3 -m venv(尽管出于某些原因,某些发行版将其分成了单独的发行版软件包,例如python3-venv在Ubuntu / Debian上)。它的作用与相同virtualenv,但仅具有部分功能(请参见此处的比较)。virtualenv继续比受欢迎venv,尤其是因为前者同时支持Python 2和3。

给初学者的建议:

这是我对初学者的个人建议:首先学习virtualenvpip,这些工具可在各种情况下与Python 2和3一起使用,并在需要时选择其他工具。

PyPI packages not in the standard library:

  • virtualenv is 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 PATH environment variable to prefix it with a custom bin directory (eg: env/bin/). An exact copy of the python or python3 binary 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.

  • is 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 PATH environment 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_VERSION environment variable, or the .python-version file, or the ~/.pyenv/version file. pyenv also makes the process of downloading and installing multiple Python versions easier, using the command pyenv install.

  • is a plugin for pyenv by the same author as pyenv, to allow you to use pyenv and virtualenv at the same time conveniently. However, if you’re using Python 3.3 or later, pyenv-virtualenv will try to run python -m venv if it is available, instead of virtualenv. You can use virtualenv and pyenv together without pyenv-virtualenv, if you don’t want the convenience features.

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

  • is a plugin for pyenv by the same author as pyenv, to conveniently integrate virtualenvwrapper into pyenv.

  • aims to combine Pipfile, pip and virtualenv into one command on the command-line. The virtualenv directory typically gets placed in ~/.local/share/virtualenvs/XXX, with XXX being a hash of the path of the project directory. This is different from virtualenv, where the directory is typically in the current working directory. pipenv is 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.

Standard library:

  • is 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 is python3 -m venv.

  • is 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-venv on Ubuntu/Debian). It serves the same purpose as virtualenv, but only has a subset of its features (see a comparison here). virtualenv continues to be more popular than venv, especially since the former supports both Python 2 and 3.

Recommendation for beginners:

This is my personal recommendation for beginners: start by learning virtualenv and 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.


回答 1

我只是避免virtualenv在Python3.3 +之后使用,而是使用标准附带的库venv。要创建新的虚拟环境,请输入:

$ python3 -m venv <MYVENV>  

virtualenv尝试将Python二进制文件复制到虚拟环境的bin目录中。但是,它不会更新嵌入到该二进制文件中的库文件链接,因此,如果您将Python从源代码构建到具有相对路径名的非系统目录中,则Python二进制文件会中断。由于这是使副本可分发的Python的方式,因此这是一个很大的缺陷。BTW使用来检查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)

因此,我会避免virtualenvwrapperpipenvpyvenv不推荐使用。pyenv似乎是经常使用的地方virtualenv使用,但我会远离它也因为我觉得venv还做什么pyenv是对建。

venv使用用户可安装的库在外壳中创建新的沙盒化的虚拟环境,并且它是多Python安全的新鲜的,因为虚拟环境只能用标准库启动船舶与Python,你必须与各地重新安装任何其他库,而虚拟环境是积极的。沙盒化,因为在虚拟环境外部看不到这些新库安装,因此您可以删除整个环境并重新启动,而不必担心会影响基本的python安装。用户可安装的库,因为创建虚拟环境的目标文件夹时没有pip installsudo在您已经拥有的某个目录中,因此您不需要sudo权限就可以在其中安装库。最终,它是多python安全的,因为在激活虚拟环境时,shell仅看到用于构建该虚拟环境的python版本(3.4、3.5等)。

pyenv类似于venv,它可以让您管理多个python环境。但是,pyenv由于无法方便地将库安装回滚到某些开始状态,因此您admin有时可能需要特权来更新库。所以我认为也最好使用venv

在过去的两年中,我发现了构建系统中的许多问题(emacs软件包,python独立应用程序构建器,安装程序…),最终归结为virtualenv。我认为当我们取消此附加选项并仅使用时,python将是一个更好的平台venv

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 <MYVENV>  

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.


回答 2

我掉进了pipenv兔子洞(的确是个黑洞和黑洞……),因为最后一个答案是两年多以前的,所以觉得有必要用有关Python虚拟信封主题的最新进展来更新讨论非常有用。找到了。

免责声明:

这个答案是不是对继续有关的优点的激烈参数pipenv VENV如信封解决方案- 我并没有任代言。这是关于PyPA赞同冲突的标准,以及如何未来发展的virtualenv承诺否定制造要么/或它们之间选择的话。我专注于这两个工具正是因为它们是PyPA的受膏工具。

静脉

如OP所述,venv是用于虚拟化环境的工具。不是第三方解决方案,而是本机工具。PyPA认可venv用于创建虚拟信封:“ 在3.5版中进行了更改:现在建议使用venv创建虚拟环境 ”。

吹牛

pipenv- venv-可以用于创建虚拟信封,但是还可以引入包管理和漏洞检查功能。通过使用 Pipfile交付软件包管理requirements.txt,而不是使用。当 PyPA认可pipenv用于包管理时,这似乎意味着取代了。pipenvpipfilerequirements.txt

但是pipenv使用virtualenv作为创建虚拟信封的工具,而不是 venvPyPA认可它为创建虚拟信封的必备工具。

标准冲突:

因此,如果解决虚拟信封解决方案还不够困难,那么我们现在让PyPA认可使用不同虚拟信封解决方案的两个不同工具。Github关于venv vs virtualenv的激烈辩论可以在这里找到该冲突的重点。

解决冲突:

上面链接中提到的Github辩论已经引导了virtualenv的开发,以适应将来的发行版中venv发展

首选内置venv:如果目标python拥有venv,我们将使用该环境创建环境(然后对其进行后续操作以促进我们提供的其他保证)

结论:

因此,看起来这两个相互竞争的虚拟信封解决方案之间将会有一些未来的融合,但是截至目前,pipenv(使用的)virtualenv与有所不同venv

鉴于pipenv解决的问题以及PyPA给予的祝福,它似乎拥有光明的前景。而且,如果virtualenv实现了其建议的开发目标,那么选择pipenvvenv不再是选择虚拟信封解决方案的理由

I’ve went down the pipenv rabbit 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.

DISCLAIMER:

This answer is NOT about continuing the raging debate about the merits of pipenv versus venv as envelope solutions- I make no endorsement of either. It’s about PyPA endorsing conflicting standards and how future development of virtualenv promises to negate making an either/or choice between them at all. I focused on these two tools precisely because they are the anointed ones by PyPA.

venv

As the OP notes, venv is a tool for virtualizing environments. NOT a third party solution, but native tool. PyPA endorses venv for creating VIRTUAL ENVELOPES: “Changed in version 3.5: The use of venv is now recommended for creating virtual environments“.

pipenv

pipenv– like venv – can be used to create virtual envelopes but additionally rolls-in package management and vulnerability checking functionality. Instead of using requirements.txt, pipenv delivers package management via Pipfile. As PyPA endorses pipenv for PACKAGE MANAGEMENT, that would seem to imply pipfile is to supplant requirements.txt.

HOWEVER: pipenv uses virtualenv as its tool for creating virtual envelopes, NOT venv which is endorsed by PyPA as the go-to tool for creating virtual envelopes.

Conflicting Standards:

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

Conflict Resolution:

The Github debate referenced in above link has steered virtualenv development in the direction of accommodating venv in future releases:

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)

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.

Given the problems pipenv solves and the fact that PyPA has given its blessing, it appears to have a bright future. And if virtualenv delivers on its proposed development objectives, choosing a virtual envelope solution should no longer be a case of either pipenv OR venv.


回答 3

2020年4月更新

当我看到这篇文章时,我正在寻找相同的内容。我认为对于像我这样的新Python用户而言,使用什么工具这个问题非常令人困惑和困难。这直接来自PyPA网站上关于pipenv的信息:

虽然本教程将pipenv项目作为工具主要集中在Python应用程序开发而不是Python库开发上,但该项目本身目前正在解决多个流程和维护问题,这些问题阻止了bug修复和新功能的发布(整个2019年过去了,而没有新版本)。这意味着,在短期内,pipenv仍然会遇到一些怪癖和性能问题,而没有明确解决这些问题的时间表。

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

假设2020年4月发布的pipenv按计划进行,此后的发布也仍在进行中,那么该教程中的警告将被删除。如果这些发行版不符合要求,那么教程本身将被删除,并替换为可用的依赖项管理选项上的讨论页。

April 2020 Update

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:

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.


声明:本站所有文章,如无特殊说明或标注,均为本站原创发布。任何个人或组织,在未征得本站同意时,禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益,可联系我们进行处理。