Ад зависимости Python: компромисс между virtualenv и глобальными зависимостями?

Question

Я уже тестировал различные способы управления моими проектными зависимостями в Python:

1. Установка всего глобального с помощью pip (экономит место, но рано или поздно приводит вас кнеприятности)
2. pip & venv или virtualenv (немного трудно справиться, но во многих случаях это нормально)
3. pipenv & pipfile (немного легче, чем venv / virtualenv, но медленно инекоторые вендоры, виртуальные envs прячутся где-то еще, кроме самой папки проекта)
4. conda в качестве менеджера пакетов и среды (отлично, если все пакеты доступны в conda, смешивать pip & conda немного нелепо)
5. Поэзия - я не пробовал это
6. ...

Моя проблема со всеми этими (кроме 1.) состоит в том, что мой жесткий диск заполняет пространстводовольно быстро: я не разработчик, я использую Python для своей повседневной работы.Поэтому у меня есть сотни небольших проектов, которые все делают свое дело.К сожалению, для 80% проектов мне нужны «большие» пакеты: numpy, pandas, scipy, matplotlib - вы называете это.Типичный небольшой проект содержит от 1000 до 2000 строк кода, но имеет 800 МБ зависимостей пакетов в venv / virtualenv / pipenv. Практически У меня около 100 ГБ моего жесткого диска, заполненного виртуальными зависимостями python.

Более того, установка всех этих компонентов в каждой виртуальной среде требует времени.Я работаю в Windows, многие пакеты не могут быть легко установлены из pip в Windows: Shapely, Fiona, GDAL - мне нужны предварительно скомпилированные диски из Кристоф Гольке .Это легко, но нарушает большинство рабочих процессов (например, pip install -r requirements.txt или pipenv install из pipfile).Я чувствую, что я на 40% устанавливаю / обновляю зависимости пакетов и только 60% своего времени пишу код.Кроме того, ни один из этих менеджеров пакетов действительно не помогает с публикацией и тестированием кода, поэтому мне нужны другие инструменты, например setuptools, tox, semantic-release, twine ...

, с которыми я говорилколлеги, но все они сталкиваются с одной и той же проблемой, и ни у кого, похоже, нет реального решения.Мне было интересно, если есть подход, чтобы некоторые пакеты, например те, которые вы используете в большинстве проектов, устанавливались глобально - например, numpy, pandas, scipy, matplotlib будут установлены с pip в C:\Python36\Lib\site-packages или conda в C:\ProgramData\Miniconda3\Lib\site-packages - это хорошо разработанные пакеты, которые не часто ломают вещи.И если я в скором времени хотел бы исправить это в своих проектах.

В локальных папках virtualenv другие вещи пойдут - у меня возникает соблазн переместить текущий рабочий процесс с pipenv на conda.

Имеет ли такой подход смысл?По крайней мере, в последнее время было много разработок в python, возможно, появилось что-то, чего я еще не видел.Существуют ли рекомендации по настройке файлов в такой смешанной глобально-локальной среде, например, как поддерживать setup.py, requirements.txt или pyproject.toml для совместного использования проектов разработки через Gitlab, Github и т. Д.?Каковы подводные камни / предостережения?

Также есть это замечательное сообщение в блоге от Криса Уоррика, которое объясняет его почти полностью.

[Обновление]

Через полгода я могу сказать, что работа с Conda решила большинство моих проблем:

• , она работает на всех системах, WSL, Windows и т. Д.
• большинство пакетов уже доступно в conda-forge, легко получить собственные пакеты, принятые в conda-forge
• для пакетов, не входящих в conda, я могу установить pip в среде conda и добавить пакеты из pypiс помощью pip
• я могу создать строгий или открытый environment.yml, указав приоритет канала conda, пакеты из conda и пакеты из pip
• . Я могу создавать среды conda из этих ymls в одномНапример, для настройки среды разработки в Gitlab Continuous Integration с использованием Miniconda3 Docker - это делает тестовые прогоны очень простыми и понятными. * Пакеты версий 1080 *
• в yml s могут быть определены строго илиоткрыть, в зависимости от ситуации.Например, вы можете исправить env в Python 3.6, но при этом получить все обновления безопасности в этом диапазоне версий (например, 3.6.9)
• Я обнаружил, что conda решает почти все проблемы с зависимостями, скомпилированными с помощью c в Windows
• относительно проблемы с "большими зависимостями": в итоге я создал много специфических (то есть маленьких) и несколько неспецифичных (то есть больших)) среды conda: например, у меня есть довольно большой jupyter_env, где установлена ​​jupyter lab и большинство моих научных пакетов (numpy, geos, pandas scipy и т. д.) - я активирую его всякий раз, когда мне нужен доступ к этим инструментам, яможет держать их в курсе в одном месте.Для разработки конкретных пакетов у меня есть дополнительные среды, которые используются только для зависимостей пакетов (например, packe1_env).Некоторые базовые инструменты установлены в базовой среде conda, например, pylint.
• Я постоянно обновляю conda с помощью Chocolatey диспетчера пакетов для Windows.choco upgrade all -Y один раз в неделю, работает как шарм!
• Новое обновление: одна из самых удивительных функций: новый флаг --stack позволяет складывать среды conda, например, conda activate my_big_env затемconda activate --stack dev_tools_env (по состоянию на 2019-02-07 ) позволяет сделать некоторые пакеты общего назначения доступными во многих envs

Одним общим недостатком является то, что при использованиибольшой конда-кузнечный канал.Они работают над этим , но в то же время индекс conda-forge очень быстро растет.

Answer 1

Обновление моего прогресса:

Менеджер пакетов Conda оказался для меня лучше, чем pipenv по следующим причинам:

• по умолчанию, глобальные зависимости доступны изнутриconda virtual envs
• это быстрее, чем pipenv при установке / обновлении зависимостей
• объединение pip и conda действительно не так проблематично, для всего, где доступен пакет conda, установите с conda, если нетпросто установите с помощью pip
• с помощью environment.yml, можно создать среду и заново создать зависимости и для Linux, и для Windows за считанные секунды - environment.yml позволяет задавать зависимости pip и conda отдельно (например, эторешает вышеуказанные проблемы с Fiona, Shapely, GDal и т. д. в Windows, используя версии conda)
• conda решает большинство проблем, связанных с поддержанием пакетов / зависимостей на разных платформах (например, linux, mac, win)
• не было проблем с установкой conda (например, miniconda) рядом сУстановка и использование независимого Python через conda через conda run
• , если в среде Environment.yml отсутствует, можно создать env из файл needs.txt (conda create -n new environment --file requirements.txt)

К сожалению,процесс создания environment.yml, кажется, нигде не описан.Через некоторое время я понял, что автоматически созданный файл (conda env export environment.yml) необходимо отредактировать вручную , чтобы он содержал наименьший возможный список зависимостей (и позволил conda решить все остальное при установке).В противном случае environment.yml не будет совместим с различными системами.

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

Есть еще некоторые недостатки,

1. Необходимо поддерживать зависимости в нескольких файлах:

   • setup.py
   • environment.yml
2. Невозможно выполнить программу напрямую (например, с помощью ярлыка) в ее среде, например, это работает без проблем с pipenv run, но:
   • conda run не будет автоматически source activate env
   • это открытый вопрос и может быть когда-нибудь решен
3. cx_freeze не будет правильно включать глобальные зависимости извне conda env
4. С conda будет сложно, если вам нужны зависимости, требующие компиляции (например, C-расширения и т. д.), см. ниже или здесь

Answer 2

Проблема

Вы перечислили ряд проблем, которые ни один подход не может решить полностью:

• пробел : «Мне нужны« большие »пакеты: numpy, pandas, scipy, matplotlib ... Практически у меня есть около 100 ГБ моего жесткого диска, заполненного виртуальными зависимостями python»
• время :«установка всего этого в каждой виртуальной среде занимает время»
• публикация : «ни один из этих менеджеров пакетов действительно не помогает с публикацией и тестированием кода»
• рабочий процесс: «У меня возникает соблазн переместить мой текущий рабочий процесс из pipenv в conda»

К счастью, вы описали не совсем классическую проблему зависимостей, которая мучает менеджеров пакетов - круговые зависимости, закрепление зависимостей, управление версиями и т. д.

---

Подробности

Я уже много лет использую conda в Windows с аналогичными ограничениями и разумным успехом.Conda изначально была разработана для упрощения установки пакетов, связанных со scipy.Это все еще делает.

Если вы используете «стек scipy» (scipy, numpy, pandas, ...), conda - ваш самый надежный выбор.

Conda can :

• установка пакетов scipy
• установка пакетов C-extensions и не-Python (необходима для запуска numpy и других пакетов))
• интеграция пакетов conda, каналов conda (вы должны изучить это) и pip для доступа к пакетам
• разделение зависимостей с виртуальными средами

Conda can't :

• помогите с публикацией кода

---

Воспроизводимые Envs

Следующие шаги должны помочьпри необходимости воспроизведите virtualenvs:

• Не устанавливайте пакеты scipy с pip.Я бы положился на Конду, чтобы сделать тяжелую работу.Это намного быстрее и стабильнее.Вы можете установить pip менее распространенные пакеты в среде conda.
• Иногда пакет pip может конфликтовать с пакетами conda в среде (см. примечания к выпуску , посвященные этой проблеме).

Избегайте проблем с пипсами:

A.Создайте рабочую среду отдельно от вашей базовой среды, например workenv.Это готовая к выполнению основная часть вашей ежедневной работы.

> conda create -n workenv python=3.7 numpy pandas matplotblib scipy
> activate workenv
(workenv)>

B.Испытайте установку необычных пакетов pip (или весомых пакетов conda) в пределах клона рабочего окружения

> conda create --name testenv --clone workenv
> activate testenv
(testenv)> pip install pint

C.Сделайте резервную копию зависимостей в requirements.txt -подобный файл с именем environment.yaml per virtualenv.При желании создайте скрипт для запуска этой команды для каждой среды.См. документы .

Публикация

Проблема с упаковкой - это отдельная проблема, которая обрела популярность с появлением файла pyproject.toml через PEP 518 (см. сообщение в блоге от автора Б. Кэннона).Инструменты упаковки, такие как flit или poetry, приняли это современное соглашение для распространения и публикации их на сервере или в индексе упаковки (PyPI).Концепция pyproject.toml пытается отойти от традиционных файлов setup.py с определенной зависимостью до setuptools.

Зависимости

Такие инструменты, как pipenv и poetry имеют уникальный современный подход к решению проблемы зависимостичерез файл блокировкиЭтот файл позволяет вам отслеживать и воспроизводить состояние ваших графиков зависимостей, что является чем-то новым в мире пакетов Python (подробнее об этом Pipfile vs. setup.py здесь ).Более того, есть утверждения, что вы все еще можете использовать эти инструменты в сочетании с Conda, хотя я не проверял степень этих утверждений.Файл блокировки еще не стандартизирован, но, по словам разработчика ядра Б. Кэнона в интервью о Будущем Python-упаковки , (~ 33 м) "Я бы хотел получитьнас там. "

Резюме

Если вы работаете с любым пакетом из стека scipy, используйте conda ( Рекомендуется ):

• Для экономии места, времени и проблем с рабочим процессом используйте conda или miniconda.
• Чтобы разрешить развертывание приложений или использование файла блокировки на ваших зависимостях, рассмотрите следующее в сочетании с conda:
  • pipenv: используйте для развертывания и выполните Pipfile.lock
  • poetry: использовать для развертывания и сделать poetry.lock
• Чтобы опубликовать библиотеку в PyPI, рассмотрим:
  • pipenv: разработка через pipenv install -e.и вручную опубликовать с помощью шпагат
  • flit: автоматически упаковать и * опубликовать
  • poetry: автоматически упаковать и опубликовать

См. Также

• Подкаст-интервью с Б. Кэнноном, обсуждающее общую проблему упаковки, pyproject.toml, блокировка файлов и инструменты .
• Подкаст-интервью с К. Рейцем, обсуждающее упаковку инструменты (pipenv против pip, 37 м) и среда разработки.

Answer 3

Мне было интересно, есть ли подход, когда некоторые пакеты, например, те, которые вы используете в большинстве проектов, устанавливаются глобально ... Другие вещи будут помещаться в локальные папки virtualenv

Да, virtualenv поддерживает это.Установите глобально необходимые пакеты глобально, а затем, когда вы создаете virtualenv, укажите параметр --system-site-packages, чтобы получающийся в результате virtualenv мог использовать глобально установленные пакеты.При использовании tox вы можете установить эту опцию в созданных virtualenvs, включив sitepackages=true в соответствующие разделы [testenv].