Today's lesson on the value of commenting your configuration settings
We have a relatively long-standing Django web application that was first written for Django 1.2 and hadn't been substantially revised since. Earlier this year I did a major rework in order to fully update it for Django 1.9; not just to be compatible, but to be (re)structured into the way that Django now wants apps to be set up.
Part of Django's app structure is a settings.py
file that contains,
well, all sorts of configuration settings for your system; you
normally get your initial version of this by having Django create
it for you. What Django wants you to have in this file and how it's
been structured has varied over Django versions, so if you have a
five year old app its settings.py
file can look nothing like what
Django would now create. Since I was doing a drastic restructuring
anyways, I decided to deal with this issue the simple way. I'd have
Django write out a new stock settings.py
file for me, as if I was
starting a project from scratch, and then I would recreate all of
the settings changes we needed. In the process I would drop any
settings that were now quietly obsolete and unnecessary.
(Since the settings file is just ordinary Python, it's easy to wind up setting 'configuration options' that no longer exist. Nothing complains that you have some extra variables defined, and in fact you're perfectly free to define your own settings that are used only by your app, so Django can't even tell.)
In the process of this, I managed to drop (well, omit copying) the
ADMINS
setting that makes Django send us email if there's an
uncaught exception (see Django's error
reporting documentation).
I didn't spot this when we deployed the new updated version of the
application (I'm not sure I even remembered this feature). I only
discovered the omission when Derek's question here
sent me looking at our configuration file to find out just what
we'd set and, well, I discovered that our current version didn't
have anything. Oops, as they say.
Looking back at our old settings.py
, I'm pretty certain that I omitted
ADMINS
simply because it didn't have any comments around it to tell
me what it did or why it was there. Without a comment, it looked like
something that old versions of Django set up but new versions didn't
need (and so didn't put into their stock settings.py
). Clearly if I'd
checked what if anything ADMINS
meant in Django 1.9 I'd have spotted
my error, but, well, people take shortcuts, myself included.
(Django does have global documentation for settings, but there is no global alphabetical index of settings so you can easily see what is and isn't a Django setting. Nor are settings grouped into namespaces to make it clear what they theoretically affect.)
This is yet another instance of some context being obvious to me
at the time I did something but it being very inobvious to me much
later. I'm sure that when I put the ADMINS
setting into the initial
settings.py
I knew exactly what I was doing and why, and it was
so obvious I didn't think it needed anything. Well, it's five years
later and all of that detail fell out of my brain and here I am,
re-learning this lesson yet again.
(When I put the ADMINS
setting and related bits and pieces back
into our settings.py
, you can bet that I added a hopefully clear
comment too. Technically it's not in settings.py
, but that's
a topic for another blog entry.)
|
|