Guidelines for using pyproject.toml with Django apps/projects?

[JK Laiho]

I'm modernizing our company's 2015-era conventions around Django projects, and one of the things I'm looking at is using pyproject.toml, both for packaging and for configuring certain tools (e.g. Black).

A bit of background. So far, we've used monorepos, with 'apps' and 'project' as the top-level directories. 'project' contains the output of 'django-admin startproject', and 'apps' contains one or more 'django-admin startapp' dirs, usually with a single 'apps/setup.py' to install them all. We like to keep Django apps separate from the Django project, so that if we decide to split one of them into a proper reusable app, we don't need to extricate it from the project package. This scheme has made both development and production deployments very easy in our particular environment.

Two points to note:

1. We like to have the 'apps' dir contents importable into the project-level runserver/gunicorn environment with just 'pip install [-e] apps', hence the setup.py file there.

2. We've never made the 'project' dir pip installable, we see it mostly as just very deployment-specific scaffolding and settings for running whatever is inside 'apps', so we tend to deploy the whole monorepo into production with Ansible and/or GitLab CI directly from our GitLab instance, followed by 'pip install apps'. Works great.

As far as point 1 goes, replacing 'apps/setup.py' with 'apps/pyproject.toml' is simple enough for our packaging needs. But we'd like to configure Black globally across the monorepo in a way that would include the 'project' directory as well. We'd need an additional pyproject.toml at the top level alongside the 'apps' and 'project' directories that has nothing at all to do with builds or packaging and only serves to configure tools.

Does this run counter to how pyproject.toml is "supposed" to be used? Does it have the potential to cause problems down the line? Are there some non-obvious factors to take into account?