#python #pip #setup.py #distutils #azure-artifacts
#python #pip #setup.py #distutils #azure-артефакты
Вопрос:
Я работаю в фирме среднего размера, где у нас есть около 10 пакетов Python и проектов, которые мы разработали внутри компании. Они частично зависят друг от друга и часто имеют одинаковые требования к пакетам, скажем pandas
, sklearn
и т.д..
Сейчас мы находимся на этапе, когда противоречащие требования вызывают проблемы при обновлении различных систем.
Мы используем платформу Azure и загружаем на нее артефакты, поэтому любой способ исправления версий там был бы наиболее предпочтительным вариантом, но я не нашел способа сделать это в документах, похоже, у вас должно быть как минимум 5 разных версий.
В идеале я хотел бы, чтобы в файлах требований просто указывалось имя пакета, а затем устанавливались версии, используемые при обновлении, путем управления тем, какие версии доступны на сервере. Есть ли хорошее решение для этого?
Варианты, которые я вижу, следующие:
-
укажите pyrc для использования частного сервера Pypi
- разместите все пакеты, используемые на этом сервере, чтобы pypi никогда не вызывался
- управляйте версиями на сервере
-
создать requirents.txt двоичный файл, который при чтении возвращает список с правильными версиями, обновляемый с какого-либо центрального сервера.
-
Дополнение к
pip
иsetup.py
, которое отправляет имена желаемых пакетов на центральный сервер и возвращает список пакетов с фиксированной версией по мере необходимости.
Есть другие, менее запутанные идеи?
Комментарии:
1. Я не совсем уверен, что понял, что вы ищете. Возможно,
constraints.txt
файлы могли бы помочь…2. @sinoroc Если я не неправильно понял, ограничения и файлы требований работают очень похоже. Я хотел бы централизованно исправить, какая версия различных пакетов используется, чтобы обновления могли выполняться на этапе блокировки и управляться из одного места, а не из 10 разных репозиториев.
3. Я могу придумать два способа. 1. Настройте и поддерживайте частный индекс и заставьте своих коллег использовать его в качестве основного индекса для pip (похоже, вы уже думали об этом). 2. Поддерживайте общий для всей компании
constraints.txt
файл (не относящийся к конкретному пакету) и создавайте своих коллег (и инструменты: CI и т.д.) Передает его в pip при каждой установке (pip install Something -c constraints.txt
), так что, если необходимо установить зависимость, и она указана вconstraints.txt
, тогда применяется ограничение диапазона версий из этого файла.4. @sinoroc это неплохая идея, если я смогу разработать аккуратный способ подачи ограничений для всех репозиториев, у нас может быть победитель. Я думаю, что git перехвачен.
5. будет ли блокировка версии
pipenv
илиpoetry
тем, что вы ищете?