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

[Anonymous]

На данный момент я тестировал различные способы управления зависимостями моего проекта в Python:

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

Моя проблема со всем этим (кроме 1.) заключается в том, что место на жестком диске заполняется довольно быстро: я Я не разработчик, использую Python для повседневной работы. Поэтому у меня сотни небольших проектов, каждый из которых делает свое дело. К сожалению, для 80% проектов мне нужны «большие» пакеты: numpy, pandas, scipy, matplotlib — что угодно. Типичный небольшой проект содержит от 1000 до 2000 строк кода, но имеет 800 МБ зависимостей пакетов в venv/virtualenv/pipenv. Виртуально У меня около 100 ГБ жесткого диска заполнено виртуальными зависимостями Python.
Более того, установка всего этого в каждой виртуальной среде требует времени. Я работаю в Windows, многие пакеты невозможно установить из pip в Windows: Shapely, Fiona, GDAL — мне нужны предварительно скомпилированные колеса от Кристофа Гольке. Это легко, но нарушает большинство рабочих процессов (например, pip install -r require.txt или Pipenv install из pipfile). У меня такое ощущение, что я на 40% устанавливаю/обновляю зависимости пакетов и только 60% времени пишу код. Кроме того, ни один из этих менеджеров пакетов на самом деле не помогает с публикацией и тестированием кода, поэтому мне нужны другие инструменты, например. setuptools, tox, semantic-release, шпагат...
Я разговаривал с коллегами, но все они сталкиваются с та же проблема, и, похоже, ни у кого нет реального решения. Мне было интересно, есть ли способ иметь некоторые пакеты, например. те, которые вы используете в большинстве проектов, устанавливаются глобально - например, numpy, pandas, scipy, matplotlib будут установлены с помощью pip в C:\Python36\Lib\ site-packages или с conda в C:\ProgramData\Miniconda3\Lib\site-packages — это хорошо разработанные пакеты, которые не часто что-то ломают. И если я все равно хотел бы исправить это в ближайшее время в своих проектах.
Другие вещи будут храниться в локальных папках virtualenv - у меня возникает соблазн переместить мой текущий рабочий процесс из Pipenv to conda.
Имеет ли вообще такой подход смысл? По крайней мере, в последнее время в Python было много разработок, возможно, появилось что-то, чего я еще не видел.
Существует ли какое-либо практическое руководство по настройке файлов в такой смешанной глобальной и локальной среде, например как поддерживать файлы setup.py, require.txt или pyproject.toml для совместного использования проектов разработки через Gitlab, Github и т. д.? Каковы подводные камни/предостережения?
Есть также замечательная запись в блоге Криса Уоррика, в которой это довольно подробно объясняется.
[Обновить 2020]
После полугода могу сказать, что работа с Conda (Миниконда) решила большую часть моих проблем:

• он работает на всех системах: WSL, Windows, Linux и т. д. conda env create -f myenv.yml одинаков на всех платформах
• большинство пакетов уже доступны на conda-forge, на conda-forge легко получить собственные пакеты.
• для тех пакетов, которых нет на conda, я могу установить pip в conda среду и добавьте пакеты из pypi с помощью pip. Подсказка: conda update --all -n myenv -c conda-forge будет обновлять только пакеты из conda, а не пакеты, установленные с помощью pip. Установленные зависимости Pip необходимо обновить вручную с помощью pip install package_name --upgrade. Обратите внимание, что установка пакетов с помощью pip в conda — это экстренное решение, которого обычно следует избегать.
• Я могу создать строгую или открытую среду.yml, указав приоритет канала conda, пакеты из conda и пакетов из pip
• Я могу создать среду conda из этих yml одним оператором, например. настроить среду разработки в Gitlab Continuous Integration с помощью Miniconda3 Docker — это делает тестирование очень простым и понятным.
• версии пакетов в yml могут определяться строгим или открытым, в зависимости от ситуации. Например. вы можете исправить env до Python 3.6, но при этом он будет получать все обновления безопасности в этом диапазоне версий (например, 3.6.9).
• Я обнаружил, что conda решает почти все проблемы с компиляцией c зависимости в Windows; conda env в Windows позволяет заморозить код Python в исполняемый файл (проверено!), который можно распространять среди конечных пользователей Windows, которые по какой-то причине не могут использовать менеджеры пакетов.
• относительно проблемы с " большие зависимости»: в итоге я создал множество конкретных (т. е. небольших) и несколько неспецифических (т. е. больших) сред conda: например, у меня довольно большой jupyter_env, где установлена ​​лаборатория Jupyter и большинство моих научных пакетов. (numpy, geos, pandas scipy и т. д.) — я активирую его всякий раз, когда мне нужен доступ к этим инструментам, я могу поддерживать их актуальность в одном месте. Для разработки конкретных пакетов у меня есть дополнительные среды, которые используются только для зависимостей пакетов (например, package1_env). Всего у меня около 10 сред, и это вполне осуществимо. Некоторые инструменты общего назначения установлены в базовой среде conda, например. пилинт. Имейте в виду: чтобы pylint/pycodestyle/autopep8 и т. д. работали (например) в VS Code, его необходимо установить в ту же среду, которая содержит зависимости кода Python - в противном случае вы получите неразрешенные предупреждения об импорте.
• Я установил miniconda с менеджером пакетов Chocolatey для Windows. Я обновляю его с помощью conda update -n base conda, а мои окружения с помощью conda update --all -n myenv -c conda-forge раз в неделю, работает просто великолепно!
  Новое обновление: доступен флаг --stack (по состоянию на 07 февраля 2019 г.), который позволяет объединять среды conda, например conda active my_big_env then conda active --stack dev_tools_env позволяет сделать некоторые пакеты общего назначения доступными во многих средах. Однако будьте осторожны: я обнаружил, что линтеры кода, такие как pylint, должны находиться в той же среде, что и зависимости линтерируемого кода.
• Новое обновление 2: я начал использовать conda из подсистемы Windows для Linux (WSL), это снова значительно улучшило мой рабочий процесс: пакеты устанавливаются быстрее, я могу работать с инсайдерами VS Code в Windows, напрямую подключенными к WSL, и в среде Linux гораздо меньше ошибок с пакетами Python.
• Еще одно обновление. Кстати, Miniconda Docker позволяет безупречно конвертировать локальные рабочие процессы conda env в контейнеризованная инфраструктура (CI и CD), тестировал это некоторое время и очень доволен - Dockerfile чище, чем в Python Docker, потому что conda управляет большей работой с зависимостями, чем pip. В настоящее время я использую это все чаще, например, при работе с лабораторией Jupyter, которая запускается из контейнера.
• да, я столкнулся с проблемами совместимости между определенными пакетами в среде conda. , но очень редко. Есть два подхода: если это важная среда, которая должна работать стабильно, включите conda config --env --setchannel_priority strict — при этом будут установлены только совместимые версии. При очень небольшом количестве и редких комбинациях пакетов это может привести к неразрешимым конфликтам зависимостей (т. е. невозможно создать окружение). В этом случае я обычно создаю меньшие окружения для экспериментальной разработки с меньшим количеством пакетов и для параметра Channel_priority установлено значение «гибкий» (по умолчанию). Иногда существуют подмножества пакетов, которые легче решить, например geoviews-core (вместо geoviews) или matplotlib-base (вместо matplotlib). Это также хороший подход, чтобы попробовать более низкие версии Python для тех экспериментальных окружений, которые неразрешимы с помощью strict, например. conda create -n jupyter_exp_env python=3.6 -c conda-forge. В крайнем случае можно установить пакеты с помощью pip, что позволяет избежать использования преобразователя пакетов conda (но может привести к нестабильной работе среды и другим проблемам, вас предупредили!). Обязательно сначала явно установите pip в свою среду.
• Один общий недостаток заключается в том, что conda работает медленно при использовании большого канала conda-forge. Они работают над этим, но в то же время индекс conda-forge растет очень быстро.

[Обновление 2021 г.]
Поскольку этот пост по-прежнему набирает много просмотров, вот субъективное обновление 2021 года:

• если вы в данных наука, (mini)conda все еще заслуживает внимания.
• в противном случае Poetry и pyproject.toml кажутся общим согласованным знаменателем.

[Обновление 2023 г.]
Я постепенно отхожу от конды. пип+

Код: Выделить всё

venv

кажется более жизнеспособным вариантом, и он часто работает лучше и быстрее (например, pytorch, трансформаторы). Забудьте о Windows: pip хорошо работает только в WSL/Linux. Для сопровождающих пакетов setuptools>64 теперь позволяет использовать пакеты только на основе pyproject.toml, что, наконец, обеспечивает унифицированный процесс создания пакетов! Избавьтесь от вашего файла setup.py. В противном случае я сейчас в основном работаю в Jupyter в Docker, где версии Python envs создаются внутри контейнеров Docker и хранятся в реестре.

Подробнее здесь: https://stackoverflow.com/questions/544 ... pendencies