On Tue, Oct 1, 2013 at 6:42 PM, Tino de Bruijn <
tin...@gmail.com> 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