Correct place to put extra startup code in django?

Question

I would like to run some environment checks when my django process starts and die noisily in the case of an error. I'm thinking things like the database has an incorrect encoding or the machine has a python version we don't support.

I'd rather our team be faced with a fatal error that they have to fix, rather than be able to ignore it.

I'm Ok with writing these checks but I'm curious about where the best place to put them is. How do I get them to execute as part of django's startup process? I thought there might be a signal I could listen too, but I can't find a relevant one in the docs.

Answer 1

I would put them in settings.py. In the past, I have put system checks like this:

try:
    from local_settings import *
except ImportError:
    print "Missing %s" % os.path.join(PROJECT_ROOT, "local_settings.py")

if DEBUG:
    for p in [PROJECT_ROOT, MEDIA_ROOT, THEME_DIR, ADMIN_MEDIA_ROOT] + list(TEMPLATE_DIRS):
        p = os.path.normpath(p)
        if not os.path.exists(p):
            print "Missing path: %s" % p

Answer 2

If you don't want to use settings module, then try project's __init__.py.

Answer 3

If you want to check that the system is correctly installed, I think that you should write your own admin command and run it as post-installation check.

I think that it doesn't worth to check if the python version is correctly installed too often especially if you are installing the django app on shared-host. My app is hosted at alwaysdata and they restart the FastCgi process every hour. These checks can have an impact on the application response time.

Answer 4

We use the top-level urls.py for this.

Answer 5

The best place to put this is into a Middleware class. Just use the Middleware to check things out before your page loads and raise an error if the check fails.

Answer 6

See http://stackoverflow.com/questions/2781383/where-to-put-django-startup-code

Answer 7

You can put it in settings.py as mentioned by others, but having code in the settings is not ideal. There is also the option of adding a handler for django.db.models.signals.class_prepared that does the desired start up checks after a specific model class is prepared.