知识问答

virtualenv和pyenv之间是什么关系？

内容 隐藏
问题：virtualenv和pyenv之间是什么关系？
回答 0
venv python> 3.3
其他工具
venv python > 3.3
Additional Tools
回答 1

问题：virtualenv和pyenv之间是什么关系？

我最近学习了如何在工作流程中使用virtualenv和virtualenvwrapper，但是我在一些指南中看到了pyenv，但是我似乎无法了解pyenv是什么以及它与virtualenv有何不同/相似。pyenv是virtualenv的更好/更新的替代品还是免费的工具？如果后者有什么不同之处，以及两者（以及适用的virtualenvwrapper）如何一起工作？

点击查看英文原文

I recently learned how to use virtualenv and virtualenvwrapper in my workflow but I’ve seen pyenv mentioned in a few guides but I can’t seem to get an understanding of what pyenv is and how it is different/similar to virtualenv. Is pyenv a better/newer replacement for virtualenv or a complimentary tool? If the latter what does it do differently and how do the two (and virtualenvwrapper if applicable) work together?

回答 0

Pyenv和virtualenv是非常不同的工具，它们以不同的方式工作以执行不同的操作：

  • Pyenv是bash扩展- 不适用于Windows-会拦截您对python，pip等的调用，以将其定向到多个系统python工具链之一。因此，您始终具有在选定的python版本中安装的所有库，因此，这对于必须在不同版本的python之间进行切换的用户而言非常有用。

  • VirtualEnv是纯python，因此可在任何地方使用，它会在激活环境中本地复制python和pip 的副本，或者可选地复制特定版本，该环境可能包含也可能不包含指向当前系统工具链的链接，如果不能，则可以仅将已知的库子集安装到该环境中。这样一来，几乎可以肯定，对于测试和部署而言，要好得多，因为您确切知道使用了哪个库，使用了哪个版本，并且全局更改不会影响您的模块。

venv python> 3.3

请注意，从Python 3.3开始，有一个名为venv的VirtualEnv内置实现（在某些安装中，有一个名为pyvenv的包装器- 在Python 3.6中已弃用该包装器），应该优先使用它。为避免包装程序可能出现问题，通常最好直接使用/path/to/python3 -m venv desired/env/path或使用pyWindows上的优秀python选择器来使用它py -3 -m venv desired/env/path。它将创建用desired/env/pathconfigure 指定的目录并适当地填充它。通常，这非常类似于使用VirtualEnv。

其他工具

有许多值得一提和考虑的工具，因为它们可以帮助使用上述一种或多种：

  • VirtualEnvWrapper管理和简化VirtualEnv- Cross平台的使用和管理。
  • pyenv-virtualenv，由pyenv-installer安装，为PyEnv工具提供了用于管理和与VirtualEnv交互的工具-通过此工具，您可以进行基本安装，包括多个版本的python，并在每个版本中创建隔离的环境-Linux / OS- X。Johann Visagie建议
  • PyInstaller可以获取可能在VirtualEnv下开发和测试的python代码，并将其捆绑在一起，以便它可以运行未安装python 版本的平台-请注意，它不是交叉编译器，因此您需要Windows（虚拟） -）机器来构建Windows安装等，但是即使您可以确定将安装python但不能确定python的版本和所有库是否与您的代码兼容，它也可以派上用场。
点击查看英文原文

Pyenv and virtualenv are very different tools that work in different ways to do different things:

  • Pyenv is a bash extension – will not work on Windows – that intercepts your calls to python, pip, etc., to direct them to one of several of the system python tool-chains. So you always have all the libraries that you have installed in the selected python version available – as such it is good for users who have to switch between different versions of python.

  • VirtualEnv, is pure python so works everywhere, it makes a copy of, optionally a specific version of, python and pip local to the activate environment which may or may not include links to the current system tool-chain, if it does not you can install just a known subset of libraries into that environment. As such it is almost certainly much better for testing and deployment as you know exactly which libraries, at which versions, are used and a global change will not impact your module.

venv python > 3.3

Note that from Python 3.3 onward there is a built in implementation of VirtualEnv called venv (with, on some installations a wrapper called pyvenv – this wrapper is deprecated in Python 3.6), which should probably be used in preference. To avoid possible issues with the wrapper it is often a good idea to use it directly by using /path/to/python3 -m venv desired/env/path or you can use the excellent py python selector on windows with py -3 -m venv desired/env/path. It will create the directory specified with desired/env/path configure and populate it appropriately. In general it is very much like using VirtualEnv.

Additional Tools

There are a number of tools that it is worth mentioning, and considering, as they can help with the use of one or more of the above:

  • VirtualEnvWrapper Manage and simplify the use and management of VirtualEnv – Cross Platform.
  • pyenv-virtualenv, installed by pyenv-installer, which gives PyEnv tools for managing and interfacing to VirtualEnv – with this you can have a base installation that includes more than one version of python and create isolated environments within each of them – Linux/OS-X. Suggested by Johann Visagie
  • PyInstaller can take your python code, possibly developed & tested under VirtualEnv, and bundle it up so that it can run one platforms that do not have your version of python installed – Note that it is not a cross compiler you will need a Windows (virtual-)machine to build Windows installs, etc., but it can be handy even where you can be sure that python will be installed but cannot be sure that the version of python and all the libraries will be compatible with your code.

回答 1

virtualenv允许您在项目的子目录中创建自定义Python安装。因此，您的每个项目python在其各自的virtualenv下都可以拥有自己的（甚至几个）项目。某些/所有virtualenv甚至具有相同版本python（例如2.7.16）而没有冲突是完全可以的-它们独立存在并且彼此不认识。如果要使用其中任何一个python，则必须使用activate它（通过运行一个脚本来临时修改您的脚本，PATH以确保virtualenv的bin/目录位于第一位）。从那时起，调用python（或其他方法pip）将调用该virtualenv的版本，直到您使用deactivate它（还原PATH）为止。

pyenv它的运行范围比virtualenv-拥有的Python安装寄存器（可用于安装新的），并允许您配置使用python命令时运行哪个版本的Python 。听起来很相似，但实际用法却有所不同。它的工作方式是（永久地）python在您的填充脚本之前添加PATH（永久），然后确定python要调用的“真实” 脚本。您甚至可以配置pyenv以调用您的virtualenv python之一（通过使用pyenv-virtualenv插件）。使用pyenv进行安装的Python版本进入其$(pyenv root)/versions/目录（默认情况下pyenv根目录为〜/ .pyenv），因此比virtualenv更“全局”。通常，您不能复制通过安装的Python版本pyenv，至少这样做不是主要思想。

要创建具有特定Python版本的virtualenv，您需要将该版本放置在系统中的某个位置（无论是否在该版本中PATH），并将其本质上克隆到新创建的virtualenv中。当然，获得特定版本的一种方法是通过安装它pyenv。完成此操作后，可以通过将不同的模块（或其版本）安装到各个虚拟环境中来自由进行区分。

简而言之：

  • virtualenv 允许您通过从现有安装中进行克隆来创建本地独立的python安装
  • pyenv 允许您同时安装不同版本的python（在系统范围内或仅针对本地用户），然后选择在任意给定时间运行哪些python（包括由virtualenv或Anaconda创建的）
点击查看英文原文

virtualenv allows you to create a custom Python installation e.g. in a subdirectory of your project. Each of your projects can thus have their own python (or even several) under their respective virtualenv. It is perfectly fine for some/all virtualenvs to even have the same version of python (e.g. 2.7.16) without conflict – they live separately and don’t know of each other. If you want to use any of those pythons, you have to activate it (by running a script which will temporarily modify your PATH to ensure that that virtualenv’s bin/ directory comes first). From that point, calling python (or pip etc.) will invoke that virtualenv’s version until you deactivate it (which restores the PATH).

pyenv operates on a wider scale than virtualenv – it holds a register of Python installations (and can be used to install new ones) and allows you to configure which version of Python to run when you use the python command. Sounds similar but practical use is a bit different. It works by prepending its shim python script to your PATH (permanently) and then deciding which “real” python to invoke. You can even configure pyenv to call into one of your virtualenv pythons (by using the pyenv-virtualenv plugin). Python versions you install using pyenv go into its $(pyenv root)/versions/ directory (by default, pyenv root is ~/.pyenv) so are more ‘global’ than virtualenv. Ordinarily, you can’t duplicate Python versions installed through pyenv, at least doing so is not the main idea.

To create a virtualenv with a specific Python version, you need to have that version somewhere in your system (whether it’s on the PATH or not) and essentially clone it into your newly created virtualenv. Of course, one way to obtain a particular version is to install it via pyenv. Once that’s done, individual virtualenvs are free to diverge by having different modules (or versions thereof) installed into them.

In short:

  • virtualenv allows you to create local, independent python installations by cloning from existing ones
  • pyenv allows you to install different versions of python simultaneously (either system-wide or just for the local user) and then choose which of the multitude of pythons to run at any given time (including those created by virtualenv or Anaconda)