About Me

PBX My name is Paul Bissex, and e-scribe.com is my consulting business. I build web applications using as much open source software as possible. From September to June I teach web design and other important non-photographic professional skills to photographers. In the '90s I wrote technology commentary and reviews for magazines, newspapers, and web publications, including Wired, Salon.com, FamilyPC, the late lamented Web Review, and the Chicago Tribune. Feel free to email me.

Book Project

I'm co-authoring a book, "Python Web Development with Django", with Jeff Forcier and Wesley Chun. It will be published by Prentice Hall in July 2008, but is available for pre-ordering on Amazon now.

Colophon

This site is built on a fresh trunk checkout of Django, running on Python 2.5.1, served by Apache and mod_python. The database is SQLite. The operating system is FreeBSD, on a VPS hosted at Johncompanies.com. Comment-spam protection by Akismet. Vintage topo imagery from the Maptech archive.

Pile o'Tags

Stuff I Use

Akismet, del.icio.us, Django, dpaste.com, Emacs, FreeBSD, Freenode, jQuery, LaunchBar, MacPorts, Markdown, Mercurial, OS X, Postfix, Python, SQLite, Subversion, TextMate, Trac, Ubuntu Linux, wmii

(Finally!)

Notes on my new Django setup

My personal record of using revision control for source code has been pretty spotty. Today I took steps toward fixing that by working out a system for managing my Django projects. I wanted revision control (Subversion), I wanted Django's "runserver" for development and mod_python for deployment, and I didn't want it to be a pain.

Some highlights of the process:

I used my pastebin site as the test mule. I checked in the current live site's source code, created "trunk", "tags", and "branches" directories per the Subversion manual, and checked out a copy of the trunk into a staging directory.
I used svn propedit svn:ignore to keep the project's SQLite database file out of the repository. Via my ~/subversion/config file I also ignore few other things such as .pyc files, just so that svn status checks aren't littered with question marks on those files.
I created a simple runserver.sh script that sets $PYTHONPATH (so that imports like from pasteproject import settings find the staging version, not my deployed version!) and starts the Django development server.
Tricky Django thing #1: I use the conditional URLconf trick in order to correctly serve media files when using the development server. The docs on this trick go on to say; "the catch here is that you'll have to remember to set DEBUG=False in your production settings file." Which brings me to...
Tricky Django thing #2: Modular settings. The first line of settings.py is: from pasteproject.settings_local import DEBUG, TEMPLATE_DEBUG, PROJECT_BASE. The file settings_local.py is not under version control, and is of course different for the development and deployment versions. It's only two lines; the first line sets DEBUG and TEMPLATE_DEBUG to True (development) or False (deployment); the custom setting PROJECT_BASE is used to locate the correct SQLite database file and the media files.

All this was a bit of work, but what it saves me in time and worry will more than make up for that.

Update: And of course it wouldn't be an upgrade if I didn't break something -- the pastebin's SQLite database permissions got set to read-only, which I fixed just now.

Sunday, October 29th, 2006
django + tips + web development
2 comments

Some related posts: Handling legacy URLs with Django • Root, sweet root • Django as superego • Offsite, online backup: rsync.net • Random crufty open source release of the day • Moving the blog to Django • The twenty-minute trouble ticket system • Django development tips • A minimal wiki in Django • Rails/Django lovefest in Chicago

• Comment from Joshua Bloom, 25 weeks later

For my Django work I'm usually developing on a windows Desktop or Laptop. When my stuff gets deployed it goes up to our linux servers.

In my urls.py files I do something like this:

if os == linux: production = True

if production: #Change where the SITE_MEDIA is being served from.
    urlpatterns += patterns('',
     (r'^site_media/(?P<path>.*)$', 'django.views.static.serve', {'document_root': '/...'}),
)
else:
    urlpatterns += patterns('',
     (r'^site_media/(?P<path>.*)$', 'django.views.static.serve', {'document_root': 'C:/...'}),
)

• Comment from Paul, 25 weeks later

Cool! I love seeing the recipes people come up with to handle deployment.

My current setup is a little different now. I no longer use a settings_local.py; I put a conditional in settings.py itself sort of like your if os... line to control DEBUG etc. I have a setting called PROJECT_BASE which is used by MEDIA_ROOT and other settings that reference the filesystem.

I no longer need the conditional URLconf trick that I linked to; if the site is running on Apache (as opposed to Django's runserver), a SetHandler None directive keeps Django from seeing any requests for static media.

I hope that we can start to incorporate some of these patterns (suitably generalized) into the framework itself as time goes on.

Name:
Email:	(Will not be shared)
Url:	(Optional)
Comment:

Search

Feeds

RSS feed

Atom feed

Older Posts

Complete archive

Spam Report

At least 36615 pieces of comment spam killed since January 12th. Thanks are mostly due to Akismet.

E-Scribe News : a programmer’s blog