Шаблон для представления пакета пакета Python (PyPi)

Question

Я пишу пару пакетов, которые я бы хотел опубликовать на PyPi для других людей.

Я не выпустили на PyPi раньше, поэтому я насмешливый до шаблона представления: https://github.com/chris-brown-nz/pypi-package-template

Вот дерево шаблона проекта:

| MANIFEST.in 
| README.rst 
| setup.cfg 
| setup.py 
|  
\---package 
     module_one.py 
     module_three.py 
     module_two.py 
     __init__.py 

С точки зрения взаимодействия с пакетом, это то, что я обычно делал бы - это лучший способ?

Для запуска метода:

from package import module_one 
module_one.ClassOne().method_a() 

Для получения значения из метода:

from package import module_two 
print(module_two.ClassFive().method_e()) 

Для установки затем использовать атрибут экземпляра:

from package import module_three 
cls = module_three.ClassSeven("Hello World") 
print(cls.value) 

«пакет 'явно зарезервированное имя и не будет использоваться в конечном проекте.

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

Answer 1

Существуют различные подходы к этому, будь то один или другой лучше зависит на том, как вы хотите развить, использование пакета (например, если вы когда-либо установить его с помощью pip install -e packag_name) и т.д.

Что отсутствует из вашего дерева имя каталога, в котором setup.py проживает, и это, как правило, имя пакета:

└── package 
    ├── package 
    │   ├── __init__.py 
    │   ├── module_one.py 
    │   ├── module_three.py 
    │   └── module_two.py 
    ├── MANIFEST.in 
    ├── README.rst 
    ├── setup.cfg 
    └── setup.py 

, как вы можете видеть, вы удвоению название «пакета», и это означает, что ваш setup.py должен быть адаптирован для каждой упаковки или динамически определять имя t где находится файл module.py. Если вы поедете по этому маршруту, я предлагаю вам поместить файлы module.py в общую папку с именем 'src' или 'lib'.

Я не люблю выше «стандартного» установки по нескольким причинам:

• это не карта хорошо к тому, как программы питона «растут», прежде чем они будут разбиты на пакеты. Перед раскалывается имея такой каталог «Src» означает использование:

  from package.src.module_one import MyModuleOneClass 
  

  Вместо этого вы бы ваши module.py файлы непосредственно под package

• Имея setup.py контролировать установку, README.rst документации и __init__.py к удовлетворить импорт Python - это одно, но все остальное, кроме ваших файлов module.py, содержащих фактическую функциональность, является мусором. Мусор, который может понадобиться в какой-то момент во время процесса создания пакета, но не нужен для функциональности пакета.

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

В частности, я всегда находил переход от использования структуры каталогов под сайт-пакеты, которые выглядели как:

└── organisation 
    ├── package1 
    └── package2 
     ├── subpack1 
     └── subpack2 

и которые могут интуитивно быть использованы как для импортирующих и навигации к исходным файлам, к чему-то вроде:

├── organisation_package1 
│   └── src 
├── organisation_package2_subpack1 
│   └── src 
└── organisation_package2_subpack2 
    └── src 

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

Для моего набора опубликованных пакетов я следовал по-другому: - Я сохранил структуру естественного дерева, которую вы можете использовать в каталогах «перед упаковкой», «src» или «lib». - У меня есть общий setup.py, который читает и анализирует (он делает не импорт) метаданные (такие как номер версии, имя пакета, информация о лицензии, установить ли утилиту (и ее название)) из словаря в __init__.py файл. В любом случае вам нужен файл. - setup.py достаточно умен, чтобы различать подкаталоги, содержащие другие пакеты, из подкаталогов, которые являются частью родительского пакета. - setup.py генерирует файлы, которые необходимы только при генерации пакета (например, setup.cfg), и удаляет их, когда они больше не нужны.

выше позволяет иметь вложенные пакеты пространств имён (т.е. package2 может быть пакет, который вы загрузить на PyPI, в дополнение к package2.subpack1 и package2.subpack2). Главное, что он (в настоящее время) не разрешает использовать pip install -e, чтобы отредактировать один пакет (а другие не доступны для редактирования). Учитывая то, как я развиваюсь, это не ограничение.

выше охватывает пространства имен пакетов, где многие другие подходы имеют проблемы с этим (помните последнюю строку дзен Python: Пространства имен одна гудение отличная идея - давайте больше тех)

примеров из выше может быть, например, найти в моих пакетах ruamel.yaml (и, например, ruamel.yaml.cmd), или в общем путем поиска PyPi для ruamel.

---

_{Как, вероятно, очевидно, стандартная оговорка: я автор из этих пакетов}

Поскольку я использую утилиту для запуска упаковки, которая также запускает тесты и выполняет другие проверки на работоспособность, общий код setup.py может быть удален из установки и вставлен в эту утилиту. Но так как обнаружение подпакетов основано на доступности setup.py, это требует некоторой доработки общего setup.py.