Last week, I went to a django presentation at HUGE Inc. in Brooklyn. For me, the highlight was Kevin Fricovsky's five minute (well, ten minute) lightning talk in which he demonstrated the power of using open source components. He took a fairly small blog project of his and pulled it down from github.com. Then he used pip to get the dependencies listed in the requirements.txt file. Inside of ten minutes, he had a working blog that used five to ten open source components.
In contrast to this, I got a big reality check on using open source code. I wanted to try out some of Steve Souders's ideas on improving website performance on a django open source project that is already running. I forked some code from github and was going to apply django-compressor to the CSS and JS to see the performance improvement. I never got to this point.
The project was missing a couple of important pieces:
- a list of the requirements and how to obtain them
- the settings.py file to list the installed apps
Without these, I was pretty much dead. I soldiered on, though, and found eight required components to add, but:
- one of the components did not work with python 2.5 at head rev
- I got a subtle templetags error message that I eventually realized meant that I had a wrong similarly-named open source component
I've written to the project author to find out where to get the correct component. It's a bracing counterpoint to the presentation. Taking your own code and adding components -- likely to work. Taking a project in an unknown state and trying to back out what the components are -- much more likely to fail.
By the way, if you get a message like this:
'XXX' is not a valid tag library: Could not load template library from django.templatetags.XXX, No module named models
then I have a technique for you. Assuming that templatetags module XXX has a ton of import statements in its files, you have to figure out which file it is importing that is causing the failure. Take code like this:
from django import template from django.conf import settings from django.core import template_loader from django.db import models from django.contrib.contenttypes.models import ContentType from django.core.exceptions import ObjectDoesNotExist from django.utils.safestring import mark_safe from syncr.twitter.models import Tweet from syncr.delicious.models import Bookmark from syncr.flickr.models import Photo from tagging.templatetags import tagging_tags from tumblr.models import TumblrPost from lastfm.models import LastfmPost import re import datetime
and turn it into this:
try:
from django import template
from django.conf import settings
from django.core import template_loader
from django.db import models
from django.contrib.contenttypes.models import ContentType
from django.core.exceptions import ObjectDoesNotExist
from django.utils.safestring import mark_safe
except ImportError, exc:
print "django error in %s: %s" % (__file__, exc)
try:
from syncr.twitter.models import Tweet
from syncr.delicious.models import Bookmark
from syncr.flickr.models import Photo
from tagging.templatetags import tagging_tags
from tumblr.models import TumblrPost
from lastfm.models import LastfmPost
except ImportError, exc:
print "package error in %s: %s" % (__file__, exc)
try:
import re
import datetime
except ImportError, exc:
print "python error in %s: %s" % (__file__, exc)
Do this for every file in the module. Run the dev server and watch for the import error location reported. Once you know which block is failing in which file, add print statements to see which particular import you get to before it fails. Then you'll know which import is not working. In my case, this showed me that I had used the wrong open source tumblr module for this project.
James Bennett has some more detailed observations on this point, too.

Leave a comment