Extending Django settings.py File

When first learning Django & python, one issue I had was how to store my settings.py file in SVN. It’s been a while and things are a little hazy, but I remember my settings.py file in my local development environment was always out of sync and I was careful not to include it in updates.

I’ve since learned a better way that is actually quite common as I have seen. I am also now using git… but that’s neither here nor there.

In my opinion, your settings.py file should only contain what should be on your live site. This should be in your repository. You can then extend your settings by adding the following at the bottom of your settings.py file:

try:
    from local_settings import *
except ImportError:
    pass

Now you can add a local_settings.py file in the same directory as your settings.py file. Simply override the settings you want such as “DEBUG = True”

Don’t add your local_settings.py file to the repository. Ideally, your live server should not have a local_settings.py file.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

May 13, 2010 · Dustin · 14 Comments
Tags:  · Posted in: Programming & Internet

  • Dmitry

    except ImportError is way better in this case.

  • http://www.nerdydork.com Dustin

    @Dmitry: duely noted and updated. I always look forward to real python gurus calling me out on these posts ;)

  • Florent V.

    This is what i did for a recent project:

    File structure:
    settings.py
    host_current.py –> symlink to the relevant host_*
    host_local.py
    host_prod.py
    host_staging.py

    In settings.py:

    # SERVER-SPECIFIC CONFIG
    # Keep at the end so it can override generic settings
    try:
    from host_current import *
    except ImportError:
    pass

  • http://www.nerdydork.com Dustin

    @Florent: that would work great unless you happen to have a windows developer on your team ;)

  • http://mikewatkins.ca/tags/python/ Michael Watkins

    Use the hostname, Luke.

    This method allows you to check in your local customizations as well, which I find very handy when I suddenly need to work on a project on a different machine.

    This isn’t specific to Django at all, but in your settings.py:

    # yes, this is available on Windows
    from socket import getfqdn

    live_host_name = ‘thelivehost.com’

    # live app specific settings
    if getfqdn() == live_host_name: foo = 1
    # development specific settings
    else: foo = 2

  • Harro

    I usually create a settings dir, add an _init_.py with the following:
    try:
    from local_settings import *
    except ImportError:
    from default_settings import *

    Then my settings go in default_settings and when someone creates a local_settings.py they simply add form default_settings import *

    This way you have access to all the variables from the default settings in your local settings so you can append as well as override them.

  • http://tirl.org Charlie

    This is the popular idiom for Django, but in my opinion it’s a little backwards. Rather than specifying “settings.py” and then importing “local_settings.py” at the end, it makes more sense to move the main settings to “default_settings.py”, and then to use “settings.py” as your local settings. At the *top* of “settings.py”, put:

    try:
    from default_settings import *
    except Import Error:
    pass

    Why? Because this way, you can truly extend the settings rather than just replacing them. You can do things like:

    INSTALLED_APPS += (‘debug_toolbar’,)

    If you just import local_settings.py at the end, you wouldn’t have INSTALLED_APPS in scope, and would have to instead redefine the whole thing.

  • http://www.catalystic.com Mark

    Another approach is to use named settings files, and point to the different settings files when calling ./manage.py [[command and params]] –settings=myproj.dev_settings and in your wsgi (if you using wsgi)

    Most of the projects I work on use development, multiple staging, and multiple production environments that each have a different set of settings (to take advantage of the multiple tenents using the django contrib sites application).

  • http://esauro.wordpress.com esauro

    IMHO having your standard development settings in settings.py is a better idea than live site, because you can checkout from repository and start working inmediatly. As well as this is easier to use some tools such as Hudson if you do so.

    To be honest in the real life most people (like me) do much more developing than deploying therefore i’d rather to have an easy start-to-develop process.

  • Warren

    We use setuptools namespace packages, in conjunction with default_settings and local_settings techniques, to spread our settings across (potentially) two deployed distributions.

    This allows us to keep all of our settings (even those for development) in version control. It also allows us to use the exact same version of the main project distribution file in both our staging and production deployments.

    =======================
    (Deployed in all environments)
    Main project distribution (project.egg):

    project_namespace_package/settings_default.py:

    # All settings. Values are appropriate for our staging
    # environment.

    project_namespace_package/settings.py:

    from project_namespace_package.settings_default import *
    try:
    from project_namespace_package.settings_local import *
    except ImportError:
    pass

    ===================
    (Only deployed in production)
    Production settings distribution (project_settings_prod.egg):

    project_namespace_package/settings_local.py:

    # Overrides for production deployment.

    ====================
    (Only deployed in our development environment)
    Development settings distribution (project_settings_dev.egg):

    project_namespace_package/settings_local.py:

    # Overrides for development environment.

  • Florent V.

    @Charlie, doing it this way (local settings in a settings.py file starting with `from default_settings import *`) is clearly better for adding to INSTALLED_APPS

  • Anonymous

    HI….for this problem you may use the named settings files i think this will help u in finding your problem.

  • http://sickboy.ru Sickboy

    Hm…For the most part I agree with your opinion about settings.py file.

  • http://homytivi.blogspot.com/ HomeTivi

    nice p0st thank for share :)