Координирует версии пакетов в организации

#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 тем, что вы ищете?