Simulating Rails like Environments in Django

- 1st November 2008

- 2 comments

I was always a fan of Rail environments and as part of some work upgrading this site to the latest version of Django I decided to clean up my whole deployment process. Part of that involved replacing everything in settings.py with the following snippet of code:

ENV = "development"
try:
    exec "from environments." + ENV + " import *"
except ImportError:
    print "You must specify a valid environment"
    exit()

I now have two settings files stored in an environments module containing all the usual django settings; one for my development environment and one suitable for live. The settings.py above is for my local development environment, with only one small change for live (this file doesn’t get deployed along with the source code for the site, so doesn’t get overwritten).

ENV = 'live'

This isn’t quite the same as the Rails implementation obviously. I run completely different server setups so I’m not too bothered about a flag on the runserver command like the -e flag for mongel. I could also probably do something to autodetect the environment but this works fine for me.

Comments

  1. I do something using regular settings files:

    1. settings_development.py
      ... all my crap here…
    1. settings_production.py
      from settings_development import *
      ... override things…
    1. settings.py
      from settings_development import *

    The stuff in settings.py assumes that the majority of the time you’ll be invoking it via runserver, so it’ll Just Work™ in development. Obviously in production you need to pass the—settings flag, but that’s all in Capistrano (or WSGI configs), right? ;)

    The naming convention is so all the files are next to each other when a directory listing is shown.

    Bradley Wright - 2nd November 2008

  2. wel I also miss the environments (symfony background)
    the exec is a pitty though, you could also use a import

    Thierry - 4th December 2008

Leave a comments