The Perfect Django Settings File | Hacker News Reader

The Perfect Django Settings File

blog.damonjablons.com

33 pointsUncle_Sam11 comments

This is far from perfect.

Using old style DATABASE settings. Questions article's up to dateness and author's knowledge.

Importing local_settings into settings like that means it's hard for local settings to add to the various lists e.g. installed apps, middleware. It's far more flexible to import a base_settings.py into settings.py (which is the local settings file).

OA's templete thing is (if I understood it correctly) total fail. Learn about django.template.loaders.app_directories.Loader

Debug status based on domain name is not scalable, prone to error and annoying (I often need to switch debug on/off in dev/staging/production(pre-launch))

I agree with some of your comments, but to be fair this was posted in October 2009, so it's almost one year old. If I'm not mistaken, the new dictionary-style DATABASES setting is from 1.2, which only came out this year.

Not sure I agree about your comment regrading settings. It's quite easy to amend values from the main settings instead of overwriting them, you just do e.g. from settings import INSTALLED_APPS, then INSTALLED_APPS += ( ... ).

That said, I've found the approach to settings outline here: http://blog.zacharyvoase.com/2010/02/03/django-project-conve... to be quite intriguing and have been meaning to investigate it and possibly start using it.

Good writeup.

One small thing I do differently: in my dev machines, I'll set and export DJANGO_DEBUG in the environment. Then in settings.py:

  import os
  DEBUG = 'DJANGO_DEBUG' in os.environ

This doesn't hardcode a single hostname in checked-in code, and works well across different machines and developers.

if socket.gethostname() == 'your.domain.com': DEBUG = False

No.

The default setting should be False, and set True only for dev.

Yikes! if socket.gethostname() == 'your.domain.com': DEBUG = False ? This is just bad advice.

I prefer to be explicit in the settings for each environment, and create a settings package, with the following modules:

- common

- development

- staging

- production

Then in each of the non-common modules import the common variables, and set your DJANGO_SETTINGS_MODULE depending on the environment. virtualenv makes this particularly easy.

Here's a writeup by Zachary Voase, who I've had the pleasure of working with more than once:

http://blog.zacharyvoase.com/2010/02/03/django-project-conve...

This is how I do my debug, seems a little more compact :)

   DEBUG = socket.gethostname() != 'your.domain.com'

I'd also suggest you add

   ADMINS = (
       ('name', 'your-email@domain.com'),
   )

and

    # Email-settings
    SERVER_EMAIL = 'your-email@domain.com'
    if DEBUG:
      EMAIL_BACKEND = 'django.core.mail.backends.console.EmailBackend'
    else:
      EMAIL_HOST = 'localhost'
      EMAIL_BACKEND = 'django.core.mail.backends.smtp.EmailBackend'

So you get notified of any errors via e-mail when debug is off.

I go for having a settings module which imports different things depending on what's available. For example, you can define host-specific settings based on hostname for different production servers (or production, staging, QA, etc), or just a 'local.py' for development. Regardless of what's imported, that file starts with "from base import *" which is where the main settings are.

For the curious, since everyone has their own way of doing this, my new-project init script is here: http://github.com/tvon/gig

I prefer using a separate settings_local.py, which overrides certain settings like DEBUG and the like. Then each environment can easily have its own settings_local file, excluded from code versioning.

one thing that I do a little differently is the template dirs

I just do a standard

    TEMPLATE_DIRS = (
        os.path.join(
            PROJECT_ROOT,
            "templates",
        ),
    )

for the template dirs and the I symlink in template directorys of apps in the project. This allows me to do any additional template wackiness(like adding another directory in the path outside the project) with a symlink rather then modifying the settings file

You should be able to throw a key-value store on top of settings to override certain values at runtime. Replace django.conf with django_dynconf?

I feel much better with the signals you have raised. But I think if you have many effects on settings you will lose the bright property of Django. Everything should start from the simplest things.

Reply on news.ycombinator.com