В чем разница между venv, pyvenv, pyenv, virtualenv, virtualenvwrapper, pipenv и т. Д.?

Question

Python 3.3 включает в свою стандартную библиотеку новый пакет venv, Что он делает, и как он отличается от всех других пакетов, которые, кажется, соответствуют регулярному выражению (py)?(v|virtual|pip)?env?

Answer 1

Пакеты PyPI не входят в стандартную библиотеку:

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

  Он работает путем установки нескольких файлов в каталоге (например: env/), а затем изменив PATH переменная окружения для префикса bin каталог (например: env/bin/). Точная копия python или же python3 Двоичный файл находится в этом каталоге, но Python запрограммирован на поиск библиотек относительно его пути в каталоге среды. Он не является частью стандартной библиотеки Python, но официально благословлен PyPA (Python Packaging Authority). После активации вы можете установить пакеты в виртуальной среде, используя pip,

• pyenv используется для изоляции версий Python. Например, вы можете проверить свой код на Python 2.6, 2.7, 3.3, 3.4 и 3.5, поэтому вам потребуется способ переключения между ними. После активации префикс 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 Кеннет Рейтц (автор requests), это самый новый проект в этом списке. Он направлен на объединение Pipfile, pip а также virtualenv в одну команду в командной строке. virtualenv каталог обычно помещается в ~/.local/share/virtualenvs/XXX, с XXX будучи хэшем пути к каталогу проекта. Это отличается от virtualenv где каталог обычно находится в текущем рабочем каталоге.

  Руководство по упаковке Python рекомендует pipenv при разработке приложений Python (в отличие от библиотек). Там, кажется, нет никаких планов поддержки venv вместо virtualenv ( № 15). Смущает, его опция командной строки --venv относится к virtualenv каталог, а не venv и аналогично, переменная окружения PIPENV_VENV_IN_PROJECT влияет на местоположение virtualenv каталог, а не venv каталог ( # 1919).

Стандартная библиотека:

• pyvenv это скрипт, поставляемый с Python 3, но устарел в Python 3.6, так как у него были проблемы (не говоря уже о непонятном имени). В Python 3.6+ точный эквивалент python3 -m venv,

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

Большинство этих инструментов дополняют друг друга. Например, pipenv интегрирует pip, virtualenv и даже pyenv при желании Единственными инструментами, которые являются настоящими альтернативами друг другу, являются: venv а также virtualenv,

Рекомендации для начинающих:

Это моя личная рекомендация для начинающих: начать с обучения virtualenv а также pip инструменты, которые работают как с Python 2 и 3, так и в различных ситуациях, и выбирают другие инструменты, как только они вам понадобятся.

Answer 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,

Answer 3

ОБНОВЛЕНИЕ 20200825:

Добавлен ниже абзац " Заключение "

Я спустился pipenvкроличья нора (это действительно глубокая и темная дыра...), и поскольку последний ответ был получен более двух лет назад, я посчитал полезным обновить обсуждение последними разработками по теме виртуальных конвертов Python, которые я нашел.

ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ:

Этот ответ НЕ о продолжении яростных дебатов о достоинствах pipenv по сравнению с venv как решений для конвертов - я не поддерживаю ни того, ни другого. Речь идет о PyPA утверждения конфликтующих стандартов и как развития будущего virtualenv обещания свести на нет, сделав или / или выбор между ними на всех. Я сосредоточился на этих двух инструментах именно потому, что они были созданы PyPA.

Venv

Как отмечается в OP, venv - это инструмент для виртуализации сред. НЕ стороннее решение, а собственный инструмент. PyPA поддерживает venv для создания ВИРТУАЛЬНЫХ КОНВЕРТОВ: " Изменено в версии 3.5: теперь рекомендуется использовать venv для создания виртуальных сред ".

pipenv

pipenv- как и venv - может использоваться для создания виртуальных конвертов, но дополнительно включает функцииуправления пакетами и проверки уязвимостей. Вместо того, чтобы использоватьrequirements.txt, pipenvобеспечивает управление пакетами через Pipfile. Поскольку PyPA поддерживает pipenv для УПРАВЛЕНИЯ ПАКЕТАМИ, это может означатьpipfile заменить requirements.txt.

ОДНАКО: pipenv использует virtualenv в качестве инструмента для создания виртуальных конвертов, а НЕ venv, который одобрен PyPA в качестве инструмента для создания виртуальных конвертов.

Противоречивые стандарты:

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

Решение конфликта:

Обсуждения Github, упомянутые в приведенной выше ссылке, направили разработку virtualenv в направлении включения venv в будущие выпуски:

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

Вывод:

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

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

Обновление 20200825:

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

Answer 4

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

В моем системном диспетчере пакетов нет версий Python, которые я хотел, или я хочу установить несколько версий Python рядом, Python 3.9.0 и Python 3.9.1, Python 3.5.3 и т. Д.

Затем используйте pyenv.

Я хочу установить и запустить несколько приложений с разными конфликтующими зависимостями.

Тогда используйте virtualenv или venv. Они почти полностью взаимозаменяемы, разница в том, что virtualenv поддерживает более старые версии Python и имеет еще несколько незначительных уникальных функций, в то время как venv находится в стандартной библиотеке.

Я разрабатываю / приложение / и мне нужно управлять своими зависимостями и управлять разрешением зависимостей в моем проекте.

Тогда используйте пипенв или стихи.

Я разрабатываю / library / или / package / и хочу указать зависимости, которые пользователи моей библиотеки должны установить.

Затем используйте setuptools.

Я использовал virtualenv, но мне не нравится, что папки virtualenv разбросаны по разным папкам проекта. Я хочу централизованное управление средами и простое управление проектами.

Затем используйте virtualenvwrapper. Вариант: pyenv-virtualenvwrapper, если вы также используете pyenv.

---

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

• pyvenv. Это устарело, используйте вместо него venv или virtualenv. Не путать с pipenv или pyenv.

Answer 5

Обновление за апрель 2020 г.

Я искал то же самое, когда наткнулся на этот пост. Я думаю, что вопрос о том, какой инструмент использовать, довольно запутан и сложен для новых пользователей Python, таких как я. Это прямо с веб-сайта PyPA относительно pipenv:

Хотя в этом руководстве проект pipenv рассматривается как инструмент, ориентированный в первую очередь на потребности разработки приложений Python, а не разработки библиотеки Python, сам проект в настоящее время работает над несколькими проблемами процесса и обслуживания, которые препятствуют публикации исправлений ошибок и новых функций (с прохождением всего 2019 года без новой версии). Это означает, что в ближайшем будущем pipenv по-прежнему страдает от нескольких причуд и проблем с производительностью без четких сроков решения этих проблем.

Хотя это остается так, разработчики проекта, вероятно, захотят изучить другие инструменты для управления зависимостями приложений для использования вместо pipenv или вместе с ним.

Если предположить, что выпуск pipenv в апреле 2020 года состоится, как и планировалось, и выпуск после него также останется на ходу, то это предупреждение в руководстве будет удалено. Если эти выпуски не останутся на ходу, само руководство будет удалено и заменено страницей обсуждения доступных параметров управления зависимостями.

Answer 6

• pyenv - управляет разными версиями python,
• все остальные - создать виртуальное окружение (которое имеет изолированную версию python и установленные "требования"),

pipenv хочет объединить все, в дополнение к предыдущему он устанавливает "требования" (в активную виртуальную среду или создает свою собственную, если ни одна из них не активна)

Так что, возможно, вам понравится только pipenv.

Но я использую: pyenv + pyenv-virtualenvwrapper, + pipenv (pipenv только для установки требований).

В Debian:

1. apt install libffi-dev

2. установить pyenv на основе https://www.tecmint.com/pyenv-install-and-manage-multiple-python-versions-in-linux/, но..

3. .. но вместо pyenv-virtualenv установите pyenv-virtualenvwrapper (это может быть автономная библиотека или плагин pyenv, здесь второй вариант):

   pyenv установить 3.9.0

   git clone https://github.com/pyenv/pyenv-virtualenvwrapper.git $(корень pyenv)/ плагины / pyenv-virtualenvwrapper

   в ~/.bashrc добавить: export $VIRTUALENVWRAPPER_PYTHON= "/ usr / bin / python3"

   источник ~/.bashrc

   pyenv virtualenvwrapper

Затем создайте виртуальные среды для своих проектов (рабочий каталог должен существовать):

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. Может, если хорошо воспользуетесь, все заменит?

Answer 7

я хочу добавитьdockerв этот список, а такжеcondaчто несколько ответов уже упоминались.

conda тяжелее, чем виртуальные среды, упомянутые в заголовке. Это также обеспечивает изоляцию некоторых системных инструментов Python, таких как драйверы ffmpeg или gpu.

docker еще лучше, он дает вам совершенно новую ОС для экспериментов. С хорошим Dockerfile иdocker build,docker runscript, у вас есть хорошая документация о том, как построена ваша среда, и ее легко заполнить, перенести в другую среду (промежуточную, производственную, облачную). Это поможет вам в долгосрочной перспективе.

Еще одно: PyCharm предоставляет несколько вариантов выбора виртуальной среды. Это помогает новичкам не беспокоиться об этом. Рекомендую использовать его, прежде чем вы узнаете, что такое виртуальная среда.

Answer 8

Как новичок в Python, этот вопрос бесконечно расстраивал меня и сбивал с толку на несколько месяцев. Какие виртуальные среды и менеджеры пакетов мне следует инвестировать в обучение, если я знаю, что буду использовать их долгие годы?

Лучшая статья, отвечающая на этот неприятный вопрос, — https://jakevdp.github.io/blog/2016/08/25/conda-myths-and-misconceptions/ Джейка Вандерпласа. Несмотря на то, что ему уже несколько лет, он дает практические ответы и историю менеджеров пакетов Python и виртуальных сред из окопов по мере развития этих современных технологий.

Это было особенно неприятно для меня в сообществах специалистов по науке о данных и «облачных вычислений больших данных», потому что conda широко используется в качестве менеджера виртуальной среды и полнофункционального менеджера пакетов для Python и JavaScript, SQL, Java, HTML5 и Jupyter Notebooks.

Так зачем вообще использовать pip, когда conda делает все, что делают варианты pip и venv?

Ответ таков: «потому что вы ДОЛЖНЫ использовать pip, если пакет conda просто недоступен». Часто требуемый пакет доступен только в формате pip, и нет простого решения, кроме как использовать pip. Вы можете научиться использовать conda buildно если вы не являетесь сопровождающим пакета, вы должны убедить владельца пакета создать пакет conda для каждого нового выпуска (или сделать это самостоятельно).

Эти пакеты на основе пипов различаются по многим важным и практическим параметрам:

• стабильность
• зрелость
• сложность
• активная поддержка (вместо смерти или смерти)
• уровни принятия рядом с «ядром» экосистемы 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 предлагает единый подход. Он поддерживается командами профессиональных разработчиков с открытым исходным кодом и имеет авторитетную компанию, предоставляющую финансирование и коммерчески поддерживаемую версию. Команды, которые поддерживают pip, venv, virtualenv, pipenv и многие другие варианты pip, по сравнению с ними имеют ограниченные ресурсы. Множество виртуальных сред pip разочаровывает новичков. Сложность инструментов виртуальной среды на основе pip, фрагментация, второстепенные и неподдерживаемые пакеты, а также крайне непоследовательная поддержка побудили меня использовать conda. Для работы по науке о данных я рекомендую использовать диспетчер виртуальной среды на основе pip в качестве последнего средства, когда пакеты conda не существуют.

Различия между вариантами venv все еще пугают меня, потому что мое время ограничено для изучения новых пакетов. pipenv, venv, pyvenv, pyenv, virtualenv, virtualenvwrapper, поэзия и другие имеют десятки отличий и сложностей, на понимание которых уходят дни. Я ненавижу идти по пути и обнаруживать, что поддержка пакета становится брюхом вверх, когда сопровождающий уходит в отставку (или становится слишком занятым, чтобы поддерживать его). Мне просто нужно сделать свою работу.

В духе полезности вот несколько ссылок, которые помогут вам нырнуть с головой, но не потеряться в Dante's Inferno (re: pip).

Руководство по виртуальной среде Python

Выбор «основных» пакетов Python для инвестиций в вашу карьеру (в долгосрочной перспективе) по сравнению с выполнением работы в краткосрочной перспективе очень важен. Однако это вопрос бизнес-анализа. Вы пытаетесь просто выполнить задачу или являетесь профессиональным инженером-программистом, который создает масштабируемые производительные системы, требующие минимального объема обслуживания с течением времени? ИМХО, conda доставит вас к последнему месту легче, чем решать проблемы множественности пунктов. В conda по-прежнему отсутствуют инструменты одноэтапной миграции pip-пакетов, что делает этот вопрос спорным. Если бы мы могли просто преобразовать пакеты pip в пакеты conda, то pypi.org и conda-forge можно было бы объединить. Pip необходим, потому что пакеты conda (пока) не универсальны. Многие программисты Python либо слишком ленивы, чтобы создавать пакеты conda, либо программируют только на Python и не нуждаются в conda.

conda стала для меня настоящей находкой, потому что она поддерживает разработку облачного программного обеспечения и потребности науки о данных в многоязычной поддержке расширений JavaScript, SQL и Jupyter Notebook, а conda хорошо работает в Docker и других облачных средах. Я призываю вас изучить и освоить conda, что позволит вам обойти многие сложные вопросы, на которые никогда не ответят инструменты, основанные на пунктах.

Будь проще! Мне нужен один пакет, который делает 90% того, что мне нужно, а также рекомендации и обходные пути для оставшихся 10% пограничных случаев.

Ознакомьтесь со статьями, указанными здесь, чтобы узнать больше о виртуальных средах на основе pip.

Я надеюсь, что это поможет оригинальному плакату и даст пищу для размышлений поклонникам пипа и конды.

Answer 9

Вот мотивация иметь единый менеджер пакетов и среды. Уменьшите сложность, несложную жизнь для питонистов, которые также являются полиглотами,

«Должен быть один — и желательно только один — очевидный способ сделать это».

Дзен Python, Тим Питерс

      Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

Answer 10

Python Docs рекомендует использовать venv поверх pyenv. Из документов:

Примечание. Начиная с Python 3.6 сценарий pyvenv объявлен устаревшим в пользу использования python3 -m venv для предотвращения возможных путаниц относительно того, на каком интерпретаторе Python будет основана виртуальная среда.

Ссылка: https://docs.python.org/3/library/venv.html