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 и т.д.?

Пакетов PyPI нет в стандартной библиотеке:

• virtualenv это очень популярный инструмент, который создает изолированные среды Python для библиотек Python. Если вы не знакомы с этим инструментом, я настоятельно рекомендую изучить его, так как это очень полезный инструмент.

  
  

  Это работает путем установки набора файлов в каталог (например: env/), а затем изменения PATH переменной окружения, чтобы добавить к ней пользовательский bin каталог (например: env/bin/). Точная копия двоичного файла python or 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; это специальные скрипты, которые на лету решают, какую версию Python запускать, на основе PYENV_VERSION переменной окружения, или .python-version файла, или ~/.pyenv/version файла. pyenv также упрощает процесс загрузки и установки нескольких версий Python с помощью команды pyenv install.

  
  



• pyenv-virtualenv это плагин для pyenv того же автора, что и pyenv, позволяющий вам использовать pyenv и virtualenv в то же время удобно. Однако, если вы используете Python 3.3 или более поздней версии, pyenv-virtualenv попытается запустить python -m venv, если он доступен, вместо virtualenv. Вы можете использовать virtualenv и 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.3 по 3.7. Он был удален из Python 3.8, поскольку у него были проблемы (не говоря уже о сбивающем с толку названии). Запуск python3 -m venv имеет точно такой же эффект, как pyvenv.

  
  



• venv это пакет, поставляемый с Python 3, который вы можете запускать, используя python3 -m venv (хотя по какой-то причине некоторые дистрибутивы выделяют его в отдельный дистрибутивный пакет, например, python3-venv в Ubuntu / Debian). Он служит той же цели, что и virtualenv, но имеет только подмножество своих функций (смотрите сравнение здесь). virtualenv продолжает оставаться более популярным, чем venv, тем более что первый поддерживает как Python 2, так и 3.

  
  

Я бы просто избегал использования virtualenv после Python3.3+ и вместо этого использовал стандартную поставляемую библиотеку 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: потому что при активации виртуальных сред оболочка видит только версию python (3.4, 3.5 и т.д.), которая использовалась для создания этой виртуальной среды.

pyenv похож на venv тем, что позволяет управлять несколькими средами python. Однако с помощью pyenv вы не сможете удобно откатывать установки библиотек до некоторого начального состояния, и вам, вероятно, в какой-то момент понадобятся admin привилегии для обновления библиотек. Поэтому я думаю, что его тоже лучше использовать venv.

За последние пару лет я обнаружил множество проблем в системах сборки (пакеты emacs, сборщики автономных приложений python, установщики ...), которые в конечном итоге сводятся к проблемам с virtualenv. Я думаю, python станет лучшей платформой, когда мы исключим эту дополнительную опцию и будем использовать только venv.

РЕДАКТИРОВАТЬ: Твит из BDFL,

Я использую venv (в stdlib) и кучу псевдонимов оболочки для быстрого переключения.

— Гвидо ван Россум (@gvanrossum) 22 октября 2020 г.

UPDATE 2020-08-25:

Added below "Conclusion" paragraph

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:

предпочитаем встроенный venv: если в целевом python есть venv, мы создадим среду, используя это (а затем выполним последующие операции с этим, чтобы обеспечить другие гарантии, которые мы предлагаем)

Заключение:

Похоже, что в будущем произойдет некоторое сближение между двумя конкурирующими решениями виртуальной оболочки, но на данный момент pipenv, который использует virtualenv, существенно отличается от venv.

Учитывая проблемыpipenv, и тот факт, что PyPA дала свое благословение, у него, кажется, светлое будущее. И если virtualenv достигает предложенных целей разработки, выбор решения для виртуальной оболочки больше не должен касаться ни pipenv, ни venv.

Обновление 2020-08-25:

Часто неоднократные критические Pipenv я видел, когда производя этот анализ, что он был не активно поддерживается. Действительно, какой смысл использовать решение, будущее которого может быть под вопросом из-за отсутствия непрерывной разработки? После перерыва, длившегося около 18 месяцев, Pipenv снова активно разрабатывается. Действительно, с тех пор были выпущены большие и существенные обновления.

Давайте начнем с проблем, которые хотят решить эти инструменты:

Не рекомендуется

• pyvenv (!=pipenv & !=pyenv). Это устарело, вместо этого используйте venv или virtualenv.