Tobias, Adam, I have "imagined" you this dialogue where you're helping people deploy an open source citizen lobbying tool in Django in an NGO was not to make you look bad of course, the intention was rather the inverse of that. This situation, and exact dialogue, I have actually had, see the source code if you don't believe me: there is a module called memopol_settings and I have actually been bitten by this. Obviously I forgot humility when I thought you would have said the same to the users as you told me on the list - because I actually have - but it's true that I was biased when I thought you would have done the same mistake as me, so, sorry for making you look like you would have yourself :)
Anyway, people from over the world have been **fighting** this situation rather than **fixing it upstream** for **ages**, see the demand: https://djangopackages.org/grids/g/configuration/ https://code.djangoproject.com/wiki/SplitSettings On one hand, I ear about all the efforts our community is doing to be inclusive, and not being just elitist trolls (like me unfortunately but working on it!!), on the other hand, we don't even provide a native and simple way for user to put their environment specific configuration in a file, despite the obvious demand (see links above, any NGO's workshop), just because we, linux experts, are experienced enough to deal with it as is. "You can't expect everybody to be a guru like you James" is what people have telling me over and over again, and what I'm working on (because my name is also James). And that's exactly why I'm trying to understand where they struggle and what's the most efficient way to fix it **upstream**, because that's my philosophy, don't fight the controls, fix them. Now, you say I can invent my own settings file system, or reuse any of the existing system. While that is perfectly true, the problem with this, is that I don't need any myself: I'm happy with env vars and a settings module, because I deploy containers and set environment varibales at container creation. At the risk of looking like a broken record (in addition to everything I already look like, "le ridicule ne tue pas" :D): it's not about me, it's not about you, it's about different users. I'm ending up with a different implementation (that i don't need) in every project I contribute to, because everyone creates their own, when after all the need is the same: they just want a configuration file outside the project with their environment specific thing. This is how I ended up with a project in my hands, that requires writing an undocumented JSON configuration file or something as warry as that. Currently I have to learn each and every environment-specific settings file app there is out there just in case somebody adds it to their project because of the lack of DJANGO_SETTINGS_FILE. After all, isn't the framework about proposing design decisions ? Doesn't it make sense for a framework to at least provide projects built on it with a way to pass a config file by path ? And really, if the django project **should** be a python module so that the settings should **always** be importable, then shouldn't startproject create a setup.py ? As you said, using django project shouldn't even **require** configuring DJANGO_SETTINGS_MODULE even at all because it's hard coded in wsgi.py and manage.py from the moment you run django-admin startproject. However, DJANGO_SETTINGS_MODULE was never designed for deployment: environment specific configuration. So really, all we need users to do, is to call `DJANGO_SETTINGS_FILE=/etc/theirconfig.py ./manage.py` (or `DJANGO_SETTINGS_FILE=/etc/memopol/production.py memopol`) to keep environment specific, non-defaults, where it belongs: outside the **public project**. Keep that in swarm, a json blob in etcd (ie. kubernetes) or in a repository with ansible playbooks, chef recipes, saltstack roles, for example it's your choice, but environment specific variables have nothing to do in the public repository anyway. About my joke on deployment debates, I recon I am in a currently mad love story that drives me a bit crazy (in a good way) with gitlab-ci and docker swarm, because it lets me treat server as cattle put a django project under continuous deployment with like ~100 SLOCs of YAML and ~5 commands on a server in NGOs that have no money to buy services such as Divio cloud or else. I love it so much, it makes me euphoric, guilty as charged, I don't feel like writing about it in a boring way where we can't indicate a joke with "<some ridiculously and obviously subjective and un-technical statement> hihihihihi ;)". Because if I were going to write on this in a boring way, I'd say perhaps making Django more comfortable to deploy for non-technical users would not be good for business. But then again, I'm not talking about commercial projects at all, rather, citizen lobbying tools and the like, software for people who strive to change the world, people without technical knowledge for example, but who have already changed how politics work at some levels with a simple camera, do we need these people ? I say yes, go diversity, lower the barrier. But my question is, do we want only people who treat servers as cattle, or do we also want newbies to be comfortable deploying Django projects which don't have invented any config file system because their maintainer doesn't need it ? Thanks for reading, and sorry in advance for all my mistakes, I'm trying not to offend anybody but obviously I'm still very young and childish, feel free to quote each of them and push me on the sloppy slope if you feel like it. But please, read the whole message, again, I'm not speaking up for myself, I'm speaking up for normal Humans, who just want to be actors of the internet, not for profit, rather than just consumers of technical people's services. -- 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 post to this group, send email to django-developers@googlegroups.com. 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/CAC6Op18x_criByEN8PwsJvVtY-BVjKCXp8BS4Awxr-TqpOKL0A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
