В чем разница между venv, pyvenv, pyenv, virtualenv, virtualenvwrapper, pipenv и т.д.?
Python 3.3 включает в свою стандартную библиотеку новый пакет venv
. Что он делает и чем отличается от всех других пакетов, соответствующих регулярному выражению (py)?(v|virtual|pip)?env
?
Переведено автоматически
Ответ 1
Это моя личная рекомендация для начинающих: начните с изучения virtualenv
и pip
, инструментов, которые работают как с Python 2, так и с 3 и в различных ситуациях, и берите в руки другие инструменты, как только они вам начнут понадобиться.
Теперь, чтобы ответить на вопрос: в чем разница между этими вещами с похожими именами: venv, virtualenv и т.д.?
Пакетов PyPI нет в стандартной библиотеке:
virtualenv
это очень популярный инструмент, который создает изолированные среды Python для библиотек Python. Если вы не знакомы с этим инструментом, я настоятельно рекомендую изучить его, так как это очень полезный инструмент.Это работает путем установки набора файлов в каталог (например:
env/
), а затем измененияPATH
переменной окружения, чтобы добавить к ней пользовательскийbin
каталог (например:env/bin/
). Точная копия двоичного файлаpython
orpython3
помещается в этот каталог, но 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.
Ответ 2
Я бы просто избегал использования 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 г.
Ответ 3
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 снова активно разрабатывается. Действительно, с тех пор были выпущены большие и существенные обновления.
Ответ 4
Давайте начнем с проблем, которые хотят решить эти инструменты:
пример использования | решение |
---|---|
В моем системном менеджере пакетов нет нужных мне версий Python, или я хочу установить несколько версий Python бок о бок, Python 3.9.0 и Python 3.9.1, Python 3.5.3 и т. Д | Тогда используйте pyenv. |
Я хочу установить и запустить несколько приложений с разными конфликтующими зависимостями. | Тогда используйте virtualenv или venv. Они почти полностью взаимозаменяемы, разница в том, что virtualenv поддерживает более старые версии python и имеет еще несколько второстепенных уникальных функций, в то время как venv находится в стандартной библиотеке. |
Я разрабатываю / application / и мне нужно управлять своими зависимостями, а также управлять разрешением зависимостей в моем проекте. | Тогда используйте pipenv или poetry. |
Я разрабатываю / library / или / package / и хочу указать зависимости, которые должны установить пользователи моей библиотеки | Тогда используйте setuptools. |
Я использовал virtualenv, но мне не нравится, когда папки virtualenv разбросаны по разным папкам проекта. Я хочу централизованное управление средами и простое управление проектами | Тогда используйте virtualenvwrapper. Вариант: pyenv-virtualenvwrapper, если вы также используете pyenv. |
Не рекомендуется