There are indeed a nice handful of apps out there that help doing this in different manners. While we're at it, my own way is to make every project a python package with a setup.py. So the settings can always be imported. Then I let docker swarm or kubernetes handle environment variables which are (surprise) environment-specific (the cherry on the top being the entry point that points to manage.py).
I'm sure everybody here has a favorite way, which works, even if it's not as pretty as my favourite way which is the prettiest in my opinion of course ;) Let alone aesthetics, DJANGO_SETTINGS_MODULE=production_settings PYTHONPATH=/etc/yourapp:$PYTHONPATH is basically a lot more error-prone than DJANGO_SETTINGS_FILE=/etc/yourapp/production.py, is it even necessary to demonstrate this ? This somewhat reminds my favorite talk this year, "Don't fight the controls", by Daniele Procida. Is there a problem to fix for any of us ? Probably not, we've been deploying django for more than a decade with DJANGO_SETTINGS_MODULE. We know are way in there, so nothing is going to change if our needs don't change or if we don't take a step back to look at the bigger picture. Do I need this to deploy my projects ? No of course, because I use the prettiest way hhihihi ;) I'm more than happy to win a debate aesthetics of automated deployment any time with gitlab ci and docker swarm or kubernetes of course, but actually that's not why that thread was even about, sorry if I misguided you, this thread is neither about you neither about me actually. Do I need this in projects which I'm not the only one to deploy ? Well now we're getting somewhere. You see, when someone makes settings.py parse a json file, or read an environment file (yes, django-environ actually has the feature to parse an environment file), it reminds of E. W. Dijkstra's quote "The computing scientist’s main challenge is not to get confused by the complexities of his own making". Do you think this kind of situation would still have happened if Django supported DJANGO_SETTINGS_FILE ? If so, would it at least be less likely ? They wouldn't need to mess with the settings file that we all share and that should not do anything more complicated than reading the existing environment according to 12factor (and my taste :)), they could just extend it and pass the path. Do I ear about projects where they invent a new per-environment configuration files ? Yeah, a lot, and you Adam, you actually have never heard about it to the point where you call it "esoteric" ? How is defining a configuration file esoteric ? What's esotheric here, is PYTHONPATH=/etc/yourapp DJANGO_SETTINGS_MODULE=production (or should it be production_settings ? doesn't matter, it'll smell a mile away anyway). DJANGO_SETTINGS_FILE=/etc/yourapp/production.py is logical and explicit. How me, kubernetes or docker swarm do env-specific-file-less configuration, can be called esoteric, but it's certainly not the other way around. I'm sure many of you maintain open source django projects which are to be installed by non technical people. I mean, I assume most of us are either making big money in big corporations either dreaming of it, but I also know most of us also dedicate a huge amount of time to contribute to NGOs with Django, or just teach django for the pleasure to share a passion. In any of this case, the project developer (us) faces a bunch of people who are really willing to learn, python, django, linux, bash, and so on, but have no experience. And this is how the drama begins, I can imagine them in front of Tobias. "How do I configure this project ?", they ask. "Just **prepend** the configuration **directory** to PYTHONPATH, and use the file name without the .py extension as DJANGO_SETTINGS_MODULE", Adam says. The user adds a file in /etc, called "memopol.py", to store their settings. Then after they do what Adam told them, itsnotworking again. "ModuleNotFoundError: No module named 'memopol.wsgi' 'memopol' is not a package". I'm sure it won't take long before Tobias begins a technical explanation (instead of working on the project itself): "Well django couldn't import WSGI anymore because it was in memopol/wsgi.py in the package, and python imported memopol from /etc now that it's first in the PYTHONPATH". "....", (it doesn't matter, the user is lost, let's talk him into a solution to cheer them up). "So what you can do for example, is to prepend something unique to your configuration file, such as _settings" "Same error" "What ??" It won't take long before Tobias figures that this project also depends on a module named memopol_settings. And that's not even the worst case scenario. Once you've been through this for a while, sharing your django projects with non technical people, you start thinking "I won't forget to ask django-dev if my friends can haz DJANGO_SETTINGS_FILE next time". And here I am today, at their service, at your service, thanks for reading. -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAC6Op18NOfN4J_Jmq%3DWqg6CpYXF87%2BDrs7dmS6TB1EtnsmAGAA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
