Python: несколько пакетов в одном репозитории или один пакет на репозиторий?

У меня есть большой проект Python 3.7+, и я сейчас разбиваю его на несколько пакетов, которые можно установить отдельно. Моя первоначальная мысль заключалась в том, чтобы создать единый репозиторий Git с несколькими пакетами, каждый со своим собственным файлом setup.py. Однако, проводя некоторое исследование в Google, я обнаружил, что люди предлагают один репозиторий для каждого пакета: (например, Python - setuptools - работа с двумя зависимыми пакетами (в одном репо?)). Однако никто не дает хорошего объяснения, почему они предпочитают такую ​​структуру.

Итак, мой вопрос следующий:

  • Каковы последствия наличия нескольких пакетов (каждый со своим файлом setup.py) в одном репозитории GitHub?
  • Могу ли я столкнуться с проблемами при такой настройке?
  • Совместимы ли общие инструменты Python (генераторы документации, упаковка pypi и т. Д.) С такой настройкой?
  • Есть ли веская причина предпочесть одну установку другому?
  • Имейте в виду, что это не вопрос, основанный на мнении. Я хочу знать, есть ли какие-либо технические проблемы или проблемы с любым из двух подходов.

Кроме того, я осведомлен (и, пожалуйста, поправьте меня, если я ошибаюсь), теперь setuptools позволяет устанавливать зависимости из репозиториев GitHub, даже если URL-адрес GitHub файла setup.py не находится в корне репозитория.


github python-3.x python python-packaging setuptools
person AstrOne    schedule 19.01.2019    source источник
comment
Преимущества отдельных пакетов: некоторые инструменты Github, такие как вики или проблемы, также можно будет разделить, и, таким образом, информация, которую они обрабатывают, будет более управляемой. Кроме того, если пользователю нужен только один из пакетов, ему не нужно загружать другие.   -  person Jalo    schedule 19.01.2019
comment
@AstrOne действительно заинтересован в том, что вы здесь придумали. Я работаю над проектом, в котором у нас было два отдельных частных пакета с собственными репозиториями, но один из пакетов зависит от другого. Это быстро превратило тестирование в кошмар. Я полагаю, мы можем либо (а) развернуть некоторую хорошую инфраструктуру DevOps CI, либо (б) поместить пакеты в одно репо и консолидировать базу тестирования. На данный момент я неравнодушен к пункту (b), учитывая, что это кажется наиболее быстрым путем, и мы все еще на начальной стадии, но очень хотим услышать, каковы лучшие практики.   -  person aaron    schedule 12.06.2019
comment
Привет! Я просто подумал, что если взаимозависимость пакетов делает выгодным хранить их в одном репозитории настолько, что пользователи предпочитают это делать, то это, вероятно, проблема с экосистемой. Я считаю, что пакеты от разных авторов обычно взаимозависимы. И, следовательно, их вряд ли когда-либо можно будет поместить в одно и то же репо (без тесного сотрудничества). Итак, если вы столкнулись с проблемами, которые все еще не решены, лучше всего их обсудить с широкой аудиторией / людьми, определяющими PEP?   -  person brezniczky    schedule 20.08.2019

Ответы (3)


arrow_upward
2
arrow_downward

Я сам исследую ту же проблему. В документации PyPa рекомендуется макет, описанный в подкаталоге "native": https://github.com/pypa/sample-namespace-packages

Я считаю, что описанная ниже структура единого пакета очень полезна, см. Обсуждение тестирования «установленной» версии. https://blog.ionelmc.ro/2014/05/25/python-packaging/#the-structure Я думаю, что это можно распространить на несколько пакетов. Опубликую, когда узнаю больше.

person boriska    schedule 26.03.2019
comment
Приведите пример потенциального использования того, что скрывается за ссылками. - person wscourge; 26.03.2019

arrow_upward
2
arrow_downward

Здесь рассматривается один аспект https://pip.readthedocs.io/en/stable/reference/pip_install/#vcs-support

В частности, если файл setup.py не находится в корневом каталоге, вам необходимо указать подкаталог, в котором можно найти файл setup.py, в команде установки pip.

Итак, если ваш макет репозитория:

  • pkg_dir/
    • setup.py # setup.py for package pkg
    • some_module.py
  • other_dir/
    • some_file
    • some_other_file

Вам нужно будет использовать pip install -e vcs + protocol: // repo_url / # egg = pkg & subdirectory = pkg_dir.

person Teitur    schedule 04.07.2019

arrow_upward
2
arrow_downward

Лучший подход? Это вопрос мнения, который не является прерогативой SO. Но вот несколько оправданий для создания отдельных пакетов:

  1. Пакет функционально не зависит от других пакетов в вашем проекте.
    То есть не импортирует из них и выполняет функцию, которая может быть полезна другим разработчикам. Дополнительные баллы, если функция, которую выполняет этот пакет, аналогична пакетам, уже имеющимся в PyPI. Дополнительные баллы, если в пакете есть стабильный API и понятная документация. Штрафные санкции, если пакет представляет собой тонкий пакет несвязанных функций, которые вы вычленили из нескольких пакетов для простоты обслуживания, но функции не имеют объединяющего принципа.
  2. Пакет не является обязательным по отношению к вашему основному проекту, поэтому могут быть случаи, когда пользователи могут разумно отказаться от его установки.
    Возможно, один пакет является клиентом, а другой - сервером. Или, возможно, пакет предоставляет возможности для конкретной ОС. Обратите внимание, что подобный пакет не функционально независим от основного проекта и поэтому не соответствует требованиям предыдущего пункта, но это все равно будет хорошей причиной для его разделения.

Я согласен с точкой зрения @boriska, что структура проекта единого пакета - это удобство обслуживания, к которому стоит стремиться. Но нет (и это только мое мнение, я собираюсь получить отрицательное голосование за его выражение) за счет загромождения индекса общедоступных пакетов большим количеством небольших пакетов, которые никогда не устанавливаются отдельно.

person BobHy    schedule 15.08.2020
comment
+1 для тех, кто никогда не устанавливался отдельно - это действительно отличный момент и хороший способ рассуждать о том, чтобы объединить несколько крошечных пакетов в один маленький. - person Joon; 13.04.2021