The subtitle of his presentation is “the power of convention”. He’s using ideas from the bash world.
manage.py startapp
is real handy to get a quick skeleton to start your
django project. You also get a settings.py
. Over the years, Vincent
started running into problems with that settings module. So he started
shopping around for ideas. See also the djangocon 2010 presentation on “why
Django sucks (and how we can fix it)”. Two comments in that presentation on
the settings module resonated with him:
“Causes headaches for deployments”
“Prevents composition of Django projects”
His current setup uses a mix of python and bash (shell) script code, with the shell script even generating some python code!
They often have multiple sites (“project” in Django speak) for one project.
Projectx/
scripts/ (Full of shell scripts)
settings/ (Yeah, a directory, not a settings.py)
site1/
site2/
One of the scripts sets up an environment with a couple of shell environment
variables, paths and sets DJANGO_SETTINGS
and so. DJANGO_SETTINGS points
to something like mysite.settings.production
, which is a production.py
inside the settings folder. Another shell script makes it easy to switch
setting modules. As all settings are python files, it is easy to find the
right one via standard shell tab completion. One of the environment variables
is used by a number of other scripts to find the project root so cdroot
gets you to the root of the project and cddjango
gets you to your actual
site.
He mentioned “djangoadmin.py” instead of “manage.py”, which I didn’t know about yet. A “runserver” shell command graps the necessary DJANGO_SETTINGS_MODULE and some other settings like port numbers and starts the django server with the correct incantations.
The last benefit he mentioned was a generated wsgi file so that you only have to add one line of setup to your apache config to get the correct settings and python paths.
Nice trick: a command that generates a couple of apache configs, one for each alternative Django settings module! Handy for testing out several configurations during development.
(Personally, I’d rather stick with buildout to set up everything as that also allows you to set up your project just right, even with multiple settings modules: just add an extra buildout .cfg file that points at a different settings file. Likewise, a wsgi file is generated. Just use the buildout django recipe.)
I’ve probably missed a couple of things, so Vincent is invited to provide more info in the comments or on his own website :-)
My name is Reinout van Rees and I program in Python, I live in the Netherlands, I cycle recumbent bikes and I have a model railway.
Most of my website content is in my weblog. You can keep up to date by subscribing to the automatic feeds (for instance with Google reader):