

The Perfect Django Settings File - Uncle_Sam
http://blog.damonjablons.com/2009/10/15/the-perfect-django-settings-file/

======
njharman
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))

~~~
jsdalton
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...](http://blog.zacharyvoase.com/2010/02/03/django-project-conventions/)
to be quite intriguing and have been meaning to investigate it and possibly
start using it.

------
redsymbol
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.

------
zalew
_if socket.gethostname() == 'your.domain.com': DEBUG = False_

No.

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

------
richardhenry
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...](http://blog.zacharyvoase.com/2010/02/03/django-project-conventions/)

------
kilian
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.

------
tvon
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>

------
BerislavLopac
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.

------
mgrouchy
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

------
jokull
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?

------
anhtran
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.

