Description
The problem
Currently it is not clearly discernible which configuration goes where. For example we have settings_base.py as well as settings.py and then some stuff which is configured via environment variables (whether IN_DOCKER is non-empty).
This I would like to change because it is not clear where to place configuration options when a new feature is introduced as well as where to configure the application when someone wants to deploy it.
Proposed solutions
As this is a problem common in the django community, multiple solutions have been thought of.
Most of them have been collected into this wiki article about split-settings but I want to present some possible solutions here as well:
- Keep the current structure but thoroughly sort through it. We would define which options go into which file and stick to it.
- Use the django-split-settings package which is similar to what we are currently doing but might offer a more structured approach.
- Use the django-configurations which uses an object-oriented approach. This would mean we could clearly define a base configuration and then adapt it into more specific environments while keeping the inherited values.
What I would also like to see is some form of configuration validation. It does not have to be super sophisticated but missing configuration options should be reported to the user.
I would like for at least @NFiedler and @timonegk to weigh in on this before I start to implement anything.