Hi Carsten, great question! The idea as i see it is: having the least amount of moving parts the better. The trick here is unification, keep a single settings file with 99% of the configuration needed using environment variables/secrets/zookeeper/etc to swap out environment specific options (activate debug mode? database connections, cache connections, domain_allowlist (formally whitelist), etc.)
This has happened a couple of times in my lifetime, stop me if you've heard it: You have N environments, they're all slightly different, you're working on local and some kind of qa environment, everything is going great, but you forgot to do that last minute change you did on the higher environments to the prod settings -- you deployed; deployment failed. Sound familiar? Having a single / or at least keeping the amount of environment setting files to a minimum will greatly benefit you in the long run, its also easier to test: remember flat is better than nested. With the method i'm suggesting, your example would not need a localconfig.py since settings.py would just import them from the environment variables. - Buzzi -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/0047aea4-d07d-4559-b613-b3ab1976a9f9o%40googlegroups.com.
