Как лучше использовать файлы pyproject.toml в иерархии проектов/приложений Django?

Я нахожусь в процессе модернизации соглашений вокруг приложений Django в нашей компании, но мне нужно многое наверстать. Одним из главных знаков вопроса сейчас является pyproject.toml, который был бы удобен (хотя и не обязателен) для настройки форматера кода Black, а также для перечисления зависимостей для pip-compile.

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

.
|_ .git
|_ apps
|  |_ app_1     # created with 'django-admin startapp'
|  |_ app_2     # likewise
|  |_ setup.py
|
|_ project      # created with 'django-admin startproject cool_site', then renamed
|  |_ manage.py
|  |_ cool_site
|     |_ __init__.py
|     |_ settings.py
|     |_ ...other files created by 'startproject'...
|
|_ support      # various helper scripts etc., not a Python package

При разработке мы использовали Vagrants или docker-compose и привязывали это репозиторий в VM или контейнер для удобства разработки на главной машине, и запускали pip install -e apps, чтобы пакеты внутри apps могли быть импортированы процессом manage.py runserver. (На наших производственных серверах мы либо развертываем это contanerized, либо просто git pull устанавливаем это репо на место с помощью Ansible, затем устанавливаем без -e, и используем gunicorn вместо runserver)

При такой структуре мы можем иметь несколько папок project или несколько сайтов внутри одной папки project (возможно, с несколькими суффиксными файлами manage_<something>.py) - ни один из них никогда не pip install сохраняется, они добавляются в PYTHONPATH тем или иным способом, а DJANGO_SETTING_FILE устанавливается в производственных развертываниях, где это необходимо.

Так много для предыстории. Вот где я запутался. pyproject.toml, кажется, в основном предназначен для упаковки, и я успешно использовал его в качестве замены apps/setup.py во время изучения этого вопроса. Однако, это также средство настройки других инструментов, например, Black. У меня нет необходимости делать содержимое папки project pip installable - приложения Django внутри apps по крайней мере в теории, если не реже на практике, могут быть использованы при различных развертываниях, но все, что находится внутри project, по сути, просто подмостки для запуска этих приложений и очень специфично для развертывания.

Цели, если возможно:

  • Настройте Black (и потенциально другие инструменты) только в одном pyproject.toml, чтобы избежать повторений, не испортив pip install возможности apps
    • Возможно, pyproject.toml на корневом уровне с только необходимыми name и version полями + Black config, никогда не используемый для целей упаковки, и еще один внутри apps с включенным ключом dependencies, который будет использоваться исключительно для упаковки/pip install - это сработает?
    • Не располагать приложения Django внутри проекта Django (т.е. избегая классического "наивного" подхода запуска
  • внутри каталога, созданного startapp) startproject

    • Подходит ли такой подход для pyproject.toml? Нам очень нравится наше монорепо, но мы не полностью женаты на этой конкретной структуре каталогов.

    Вернуться на верх