Когда вы разрабатываете проект Python, вам необходимо установить зависимости проекта. В течение долгого времени учебные пособия и статьи говорили вам использовать виртуальную среду для изоляции зависимостей проекта. Таким образом, вы не загрязняете рабочий набор других проектов или глобального переводчика, чтобы избежать возможных конфликтов версий. Обычно мы должны делать эти вещи:
$ python3 -m venv venv # make a virtualenv named `venv` $ . venv/bin/activate # activate the virtualenv (venv) $ pip install -r requirements.txt # install the dependencies
Есть также инструменты рабочего процесса, которые упрощают этот процесс, такие как Pipenv и Поэзия Анкет Они создают для вас виртуальные среды без восприятия, а затем устанавливают в них зависимости. Они используются широким спектром пользователей. Виртуальная среда содержит интерпретатор Python и имеет такую же структуру каталогов, что и нормальная установка, чтобы ее можно было использовать так, как если бы это была автономная установка Python.
Проблемы с виртуальными средами
VirtualEnvs помогают нам изолировать зависимости проекта, но все становится сложным, когда речь заходит о вложенных Венвах: один устанавливает менеджер VirtualENV (например, Pipenv или поэзия) с использованием инкапсулированного Venv Python и создает больше Venvs, используя инструмент, основанный на инкапсулированном Python. Однажды выйдет незначительное выпуск Python, и нужно проверить все эти Venvs и обновить их, если это необходимо, прежде чем они смогут безопасно удалить версию Python, устаревшую версию Python.
Другой сценарий – глобальные инструменты. Есть много инструментов, которые не привязаны к каким -либо конкретным виртуальным вопросам и должны работать с каждым из них. Примерами являются инструменты профилирования и сторонние зареалы. Мы также хотим, чтобы они были установлены в собственных изолированных средах. Невозможно заставить их работать с VirtualEnv, даже если вы активировали виртуальный проект целевого проекта, над которым вы хотите поработать, потому что инструмент лежит в своем собственном VirtualEnv, и он может видеть только библиотеки, установленные в нем. Поэтому мы должны установить инструмент для каждого проекта.
Я поддерживал проект Pipenv в качестве сотрудничества в течение последних двух лет и стал членом PYPA в начале 2020 года. Я всегда думаю, что виртуальная среда действительно обязательно для проектов Python, как npm , это не нуждается в клонированном Узел Бинарный, но Просто node_modules каталог, который уникален для каждого проекта.
PEP 582 – Справочник Python Local Packages
Решение существует в течение долгого времени. PEP 582 был создан в 2018 году и до сих пор является проектным предложением до того времени, когда я написал эту статью, но я узнал, что именно то, что node_modules в питоне.
Скажем, у вас есть проект со следующей структурой:
. ├── __pypackages__ │ └── 3.8 │ └── lib └── my_script.py
Как указано в PEP 582, если вы запускаете python3.8/path/to/my_script.py , __pypackages __/3.8/lib будет добавлено в sys.path и библиотеки внутри станут импортируемыми в my_script.py Анкет
Теперь давайте рассмотрим две проблемы, которые я упомянул в последнем разделе, и посмотрим, как они меняются с силой PEP 582. Для первой проблемы основная причина заключается в том, что виртуальная среда связана с клонированным интерпретатором Python, на котором основан последующий поиск библиотеки. Он использует преимущества существующих механизмов Python без каких -либо других сложных изменений, но делает всю виртуальную среду стать недоступной, когда интерпретатор Python является устаревшим. В каталоге локальных пакетов у вас больше нет интерпретатора Python, путь библиотеки напрямую добавляется к sys.path , Таким образом, вы можете свободно перемещать и скопировать его.
Второе, еще раз, вы просто называете инструмент против проекта, который хотите проанализировать, и __pypackages__ Сидеть внутри проекта будет загружена автоматически. Таким образом, вам нужно сохранить только одну копию глобального инструмента и заставить его работать с несколькими проектами.
PDM – новый менеджер пакетов Python и инструмент рабочего процесса
Начиная с PEP, я сделал PDM , новый диспетчер пакетов Python и инструмент рабочего процесса, который использует PEP 582, чтобы полностью избавиться от VirtualENV. Он устанавливает зависимости в локальный каталог пакетов __package__ и рассказывает о переводчиках Python об этом с Очень простая настройка Анкет Это не только реализация PEP 582, но и единственный менеджер пакетов, который поддерживает PEP 621 , новый формат метаданных, основанный на pyproject.toml который становится стандартом в последнее время. Предполагается, что PIP также постепенно поддержит этот формат. Кроме того, PDM использует тот же резолювер зависимостей, что и PIP, и имеет полнофункциональную систему плагина, позволяющая плагинам, управляемым сообществом для улучшения функциональных возможностей.
В PDM PEP 582 не является обязательным, вы также можете придерживаться VirtualEnv. PDM может обнаружить Существующий Венва, но не создают новые.
Еще одна вещь, которая заслуживает внимания, – это механизм разрешения зависимостей – он пытается заблокировать версии, которые совместимы с Требуется питон ценность проекта. Скажем, ваш проект требует Python 2.7 или 3.6 Верхний И вы хотите добавить питест как зависимость развития, в Pipenv (вер. 2020.11.15 ) Вы должны прикрепить pytest вручную в Pipfile . И в поэзии (вер. 1.1.4 ), если вы запускаете Поэзия добавить -Д -pytest ты получишь:
The current project's Python requirement (>=2.7,<3.0 || >=3.6,<4.0) is not compatible with some of the required packages Python requirement:
- pytest requires Python >=3.6, so it will not be satisfied for Python >=2.7,<3.0
Да, это говорит вам обновить ваш Python, требуется версия. Однако в PDM вы можете успешно заблокировать:
❯ pdm add -d pytest Adding packages to dev dependencies: pytest ✔ 🔒 Lock successful Changes are written to pdm.lock. Changes are written to pyproject.toml. Synchronizing working set with lock file: 11 to add, 0 to update, 0 to remove ✔ Install atomicwrites 1.4.0 successful ✔ Install colorama 0.4.4 successful ✔ Install packaging 20.8 successful ✔ Install more-itertools 5.0.0 successful ✔ Install pyparsing 2.4.7 successful ✔ Install attrs 20.3.0 successful ✔ Install pluggy 0.13.1 successful ✔ Install py 1.10.0 successful ✔ Install pytest 4.6.11 successful ✔ Install six 1.15.0 successful ✔ Install wcwidth 0.2.5 successful 🎉 All complete!
Как видите, pytest прикреплен к 4 * Это совместимо с Python 2.7 и Python 3.6+.
Для получения дополнительных функций и демонстраций, пожалуйста, обратитесь к Сайт PDM и GitHub Repo Анкет
Некоторые случайные слова
Вы, возможно, видели это комикс Раньше в мире Python уже так много менеджеров пакетов, нужен ли нам новый? Нет, я думаю. С радостью мы видели много улучшений в экосистеме упаковки Python и официального установщика PIP, таких как PEP 517 / PEP 518 и Новое разрешение зависимостей , еще больше в будущем. Но до того, как наступит день, почему бы не попробовать что -то отличное от традиционного, почему бы не сделать что -то новое, что, по крайней мере, делает меня счастливым. Если вы так думаете, PDM должен быть вариантом, надеюсь.
Оригинал: “https://dev.to/frostming/you-don-t-really-need-a-virtualenv-4bae”