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

Ответы (6)

Рекомендация для новичков:

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

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

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

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

  • pyenv используется для изоляции версий Python. Например, вы можете протестировать свой код на Python 2.7, 3.6, 3.7 и 3.8, поэтому вам понадобится способ переключения между ними. После активации он добавляет к переменной среды PATH префикс ~ / .pyenv / shims, где есть специальные файлы, соответствующие командам Python (python, пункт). Это не копии команд, поставляемых с Python; это специальные сценарии, которые решают на лету, какую версию Python запускать, на основе переменной среды PYENV_VERSION, файла .python-version или ~ /. pyenv / версия файл.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 (см. docs). Он дает вам такие команды, как 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, например поэзия, которые я не буду здесь перечислять, поскольку этот вопрос касается только пакетов с аналогичными названиями.

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

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

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

Я бы просто избегал использования virtualenv после Python3.3 + и вместо этого использовал бы стандартную поставляемую библиотеку venv. Чтобы создать новую виртуальную среду, введите:

$ python3 -m venv   

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.

Fresh: поскольку виртуальные среды начинаются только со стандартными библиотеками, которые поставляются с python, вам необходимо заново установить любые другие библиотеки с помощью pip install, пока виртуальная среда активна. .

Изолированный: поскольку ни одна из этих новых установок библиотеки не видна за пределами виртуальной среды, вы можете удалить всю среду и начать заново, не беспокоясь о влиянии на вашу базовую установку python.

Библиотеки, устанавливаемые пользователем: поскольку целевая папка виртуальной среды создается без sudo в каком-то каталоге, который у вас уже есть, вам не понадобится sudoразрешения на установку в него библиотек.

безопасный для нескольких Python: поскольку при активации виртуальных сред оболочка видит только версию Python (3.4, 3.5 и т. Д.), Которая использовалась для создания этой виртуальной среды.

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

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

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

22 октября 2020

UPDATE 20200825:

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:

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.

Update 20200825:

An oft repeated criticism of Pipenv I saw when producing this analysis was that it was not actively maintained. Indeed, what's the point of using a solution whose future could be seen questionable due to lack of continuous development? After a dry spell of about 18 months, Pipenv is once again being actively developed. Indeed, large and material updates have since been released.

  • pyenv - manages different python versions,
  • all others - create virtual environment (which has isolated python version and installed "requirements"),

pipenv want combine all, in addition to previous it installs "requirements" (into the active virtual environment or create its own if none is active)

So maybe you will be happy with pipenv only.

But I use: pyenv + pyenv-virtualenvwrapper, + pipenv (pipenv for installing requirements only).

In Debian:

  1. apt install libffi-dev

  2. install pyenv based on https://www.tecmint.com/pyenv-install-and-manage-multiple-python-versions-in-linux/, but..

  3. .. but instead of pyenv-virtualenv install pyenv-virtualenvwrapper (which can be standalone library or pyenv plugin, here the 2nd option):

    $ pyenv install 3.9.0
    
    $ git clone https://github.com/pyenv/pyenv-virtualenvwrapper.git $(pyenv root)/plugins/pyenv-virtualenvwrapper
    # inside ~/.bashrc add:
    # export $VIRTUALENVWRAPPER_PYTHON="/usr/bin/python3"
    $ source ~/.bashrc
    
    $ pyenv virtualenvwrapper
    

Then create virtual environments for your projects (workingdir must exist):

pyenv local 3.9.0  # to prevent 'interpreter not found' in mkvirtualenv
python -m pip install --upgrade pip setuptools wheel
mkvirtualenv  -p python3.9 -a 

and switch between projects:

workon 
python -m pip install --upgrade pip setuptools wheel pipenv

Inside a project I have the file requirements.txt, without fixing the versions inside (if some version limitation is not neccessary). You have 2 possible tools to install them into the current virtual environment: pip-tools or pipenv. Lets say you will use pipenv:

pipenv install -r requirements.txt

this will create Pipfile and Pipfile.lock files, fixed versions are in the 2nd one. If you want reinstall somewhere exactly same versions then (Pipfile.lock must be present):

pipenv install

Remember that Pipfile.lock is related to some Python version and need to be recreated if you use a different one.

As you see I write requirements.txt. This has some problems: You must remove a removed package from Pipfile too. So writing Pipfile directly is probably better.

So you can see I use pipenv very poorly. Maybe if you will use it well, it can replace everything?

EDIT 2021.01: I have changed my stack to: pyenv + pyenv-virtualenvwrapper + poetry. Ie. I use no apt or pip installation of virtualenv or virtualenvwrapper, and instead I install pyenv's plugin pyenv-virtualenvwrapper. This is easier way.

Poetry is great for me:

poetry add    # install single package
poetry remove 
poetry install   # if you remove poetry.lock poetry will re-calculate versions

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

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

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

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

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

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

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

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

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

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

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


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

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

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

@ Flimm очень хорошо объяснил все различия. Как правило, мы хотим знать разницу между всеми инструментами, потому что мы хотим решить, что лучше для нас. Итак, следующий вопрос: какой использовать? Предлагаю вам выбрать один из двух официальных способов управления виртуальными средами:

2022 WebDevInsider