On Tue, Oct 1, 2013 at 6:42 PM, Tino de Bruijn <[email protected]> wrote: > To all of you who don't see benefit in putting certain (definitely not all!) > settings in the environment, I would like to say: try it. It will finally > make sense that you set DJANGO_SETTINGS_MODULE in the first place. I never > understood why anybody would want that until this :D. > > I was sceptical first as well, but tried out Heroku and therefore this > method. I have since converted all projects to a structure where environment > specific variables are stored, well, in the environment. Still my settings > is a module, where prod.py and dev.py inherit from common.py, but that is > mainly because certain apps are not necessary on either dev of production > servers. So that is all checked into the repository. I don't see any > necessity to store those environment vars in a repository, as they contain > login keys and static files buckets etc.
Tracking what login keys are assigned to a specific instance of an application is the entire purpose of configuration management. The reason we keep code in VCS is so that we can be assured what is deployed is coherent and consistent, the same is true for configuration, it must be known and verifiable. The entire basis of my position is that configuration is essential code which must be tracked and be verifiable with an audit history of changes. If you don't feel that to be the case, you are unlikely to see the benefit in your configuration. The second benefit is in consistency. Both approaches take the same overall method, one file contains secrets/host specific configuration for this server, the second contains generic configuration, and the two are combined. With the environment variables way, where is your host specific configuration? It could be in .login, in a gunicorn launch script, in a shell script - anywhere. How is the configuration defined? Are you "setenv foo bar" because this host is Solaris and you're running csh, or is this an "export foo=bar". Perhaps they are in your supervisord configuration. Compare to using a python file - you have full power of the python interpreter to do whatever you need. Everything is in one language, the same language as your code. All configuration will apply regardless of how you start the server, whether it is supervisord launching a wsgi process or you running runserver. There is no requirement for this file to belong to the same repository as the code, or even be in a repository. There is absolutely nothing that using environment variables as a source of configuration gives you that you cannot do using a python configuration file and it makes your configuration management messy and chaotic. Cheers Tom -- You received this message because you are subscribed to the Google Groups "Django developers" 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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAFHbX1LTavB%2BreZDONOAmq2OZvtsEhcCc5q5ymn3JAisy3iALg%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
