Last update on .

The Old Blog

I started blogging with a plain HTML file. I would simply append new entries to the top. The motivation was to have a place to record technical solutions that I repeatedly had to look up. The setup was functional, but didn’t look very sophisticated. It stopped being practical when I wanted to categorize entries on different topics.

I decided to upgrade a couple of years ago. I was learning python and figured that while I was at it I would brush up on my CSS+HTML skills. I chose PyBlosxom because I could actually understand the CGI script, and I created a layout with floats and divs. It worked pretty well, but due to a busy job schedule and switching hosting providers, I didn’t keep it up.

I really like PyBlosxom. It is ideal in its simplicity. It’s clear to deploy, the templates are easy to configure, and (best of all) the content is just ASCII text files in a directory. The categories come from the directory name, and the posting timestamp comes from the file name. This makes the blog very archive-able. Being able to access my data in twenty years is important if I’m going to invest any time and energy into creating it (thank goodness for the Internet Archive).

Unfortunately, PyBlosxom didn’t provide a lot of the niceties of a modern blogging platform. As my wife started using Blogger, I became envious of things like pingback support, feed subscriptions, and open-id authentication. I decided it was time to move on.

Discovering Django

I have played with a few web frameworks since learning Python. I’ve been searching for something as accessible as PHP, but better designed. I really like Spyce. It is well thought out, and I became a better engineer by tinkering with the framework. Unfortunately it doesn’t have much of a following. I missed the extensive documentation, libraries, and community I enjoyed as a young PHP coder. The enormous mindshare of PHP does bring some value.

Last year I discovered Django, and I’m hooked. It works the way I think. It is still pretty young, but it has a lot of momentum and I’m optimistic that it is maturing well. In my opinion, it is very successful at bringing the beauty of python to web application development.

Unfortunately, Django applications are very immature. Though initiatives have begun, there is not yet a central registry with ratings where good applications and plugins can gain mindshare and following. The Django community hasn’t yet developed habits like releasing code, preserving interfaces, and working off of stable versions. Though Django makes it very easy to build any application I might need, maintaining all of the nuts and bolts of my application makes it hard to compete with the PHP administrator who configures a couple of Drupal plugins and calls the site done. Most users won’t notice the difference in quality.

This realization led me to reexamine Drupal. I gave it a fair shot. Drupal does its job well, but it just isn’t elegant enough—it still feels like a PHP application. My python experience has made me finicky. Doggonit, I want a Django blogging application.

Bruce Kroeze says it well in his [blog post from 2007](http://coderseye.com/2007/banjo-blog-nearing-01-release.html]:

Blogs look simple, and stripped of everything else, they really are simple. Basically they are just reverse chronological posting of text on a page. No biggie, at least at first or second glance.

But the trick is in the phrase ‘stripped of everything else.’ Once you start considering the features commonly available in blog apps, it gets quite a bit more complex…”

The same can be said for a CMS, a shopping cart, or a photo gallery.

Getting Banjo

In the quoted blog post, Bruce Kroeze proceeds to describe Banjo: “the Django blogging application with bells and whistles”. Though immature when compared with some of the PHP blogging applications, Banjo has an impressive feature list. And being based on Django means that it should have a straightforward templating system and clean hooks for customization (this is where Drupal gave me a huge headache). It appears to be the only attempt at building a Django blog that has developed a proto–community. After mulling it over a number of months, I decided it was time to get my blog back online and give Banjo a test-drive.

Oh, The Agony

Deploying Banjo is not easy. The website is really a bunch of stub pages, and the mailing list is pretty quiet (I’ll have to save my rant about why Google Groups is awful for another post). What follows isn’t really a howto, but more of a map of the gotchas I dealt with in deploying Banjo.

I started by doing an hg clone http://hg.assembla.com/banjo and then followed the instructions here. Those instructions aren’t too bad—but the list of dependencies to install is daunting. High on the list is Satchmo—a Django shopping cart solution. It does seem odd for a blog to depend on a shopping cart, but Bruce Kroeze is a principle author of both applications and wanted to leverage some of the Satchmo libraries. Most of Satchmo is unnecessary—I’ll provide the details later. Unfortunately, Satchmo has its own daunting list of dependencies that must be installed. The dependencies are frustrating for a few reasons:

  • Some of the projects depended on by Banjo and Satchmo appear to be abandoned.
  • Some of the projects are disorganized, making it unclear which of the project source repositories is the most recent and compatible with Banjo.
  • Some of the projects depended on by Banjo and Satchmo are under active development, but Banjo hasn’t seen any commits in a while, which makes me nervous that there will be breakage.
  • I have to monitor all of these dependencies for security patches, instead of letting the Banjo community or my distribution security team do it for me.
  • It’s simply a lot of installs (16 outside of my package management system), and when you include the source histories for all of these projects it becomes a chunk of disk space (129M for a blog!).
  • Banjo usually depends on the unreleased source tips, instead of a specific released version. Making for a lot of moving developer targets.
  • Not all of the dependencies are listed on the install instructions for Banjo or Satchmo.

The list of dependencies provided here is complete as of the day of this blog post. When it was necessary to check out source tips, I found that Banjo worked with the sources as checked out in early February 2009.

A note on installing python packages: As a general rule, I don’t use Python’s setup.py functionality to install packages, nor do I use methods that call setup.py such as easy_install and pip. Python’s distutils has two major problems:

  • there is no clean uninstallation,
  • it mixes manually maintained packages with ones that the package manager will track for me.

Instead, I copy the uncompressed files into a common directory and add that directory to my sys.path at the top of my Django settings.py. Sometimes it helps to check the Python Package Index (pypi.python.org) to find the latest released version. Occasionally it is necessary to run setup.py build and copy the files out of the build directory.

My prerequisites:

  • Debian Lenny
  • PostgreSQL
  • Python 2.5
  • python-psycopg2
  • Apache
  • mod_python
  • memcached

I also had django-1.0 installed and running when I started setting up Banjo.

Dependencies:

  • python-yaml from aptitude.
  • python-simplejson from aptitude. I didn’t see this listed on the Banjo or Satchmo docs.
  • python-imaging from aptitude.
  • Django (svn tip just after version 1.1 alpha—Banjo doesn’t work with version 1.0). I wish Banjo stuck with the released version.
  • django-registration (version 0.7 from pypi). This project is under active development.
  • iso8601 (version 0.1.4 from pypi). This project appears mature but not active.
  • typogrify (v 1.0). I didn’t see this requirement listed in the docs.
  • sorl-thumbnail (svn tip). This project appears mature and maintained, though they don’t ever bundle their releases for download.
  • django-template-utils (release 0.4p2 would probably work, but I used svn trunk because the one additional change looked safe). This project looks mature, but not very active. The Banjo installation instructions need to be updated to reflect this dependency.
  • django-evolution (svn checkout). This is an active project.
  • django-extensions (svn tip). This is an active project with a large community. It must be called “extensions” for Banjo to import it.
  • django-atompub (svn checkout). The project doesn’t look active.
  • django-xmlrpc (bzr trunk—version 0.1 doesn’t work). Don’t be deceived by the link to Google Code as the project’s home page (the Google Code svn source doesn’t work); Launchpad is the right place. The Banjo instructions need to be updated as well. This project doesn’t look actively maintained, especially since the source requires a trivial edit to atom.py (add an import re) to import. A patch was reported six months ago and hasn’t been applied.
  • django-app-plugins (svn trunk). Project appears active, but has some trivial problems like missing a license notice (I just submitted the issue). The website says it’s released under the MIT license.
  • django-threaded-multihost (version 1.3-0 downloaded from www.assembla.com/spaces/threaded_multihost/ documents). This project doesn’t look used outside of Banjo and Satchmo—not much of a community. But it appears to work well. One note: the released tar.gz does not contain the license and docs that are in the hg repo.
  • django-site-skins (hg trunk). This was recently spun off of Banjo and Satchmo, and isn’t listed as a dependency in the docs.
  • django-admin-plugins (hg clone of tip at http://hg.assembla.com/adminplugins). This is another Banjo/Satchmo library.
  • Satchmo (release 0.8.1 might work because Banjo hasn’t changed much since then, but I downloaded the svn trunk). This is a Django shopping cart with a good community. However, Banjo only needs a couple of the Satchmo libraries.
  • Banjo (hg checkout of http://hg.assembla.com/banjo. I didn’t try the 0.9-1 release downloadable from assembla).

I only had to make sure that a couple of Satchmo modules were in my python system path. I got them there by symlinking them into the common directory which I appended to sys.path. The source doesn’t appear to import anything else from Satchmo, so deleting the rest should be possible.

Satchmo modules:

  • keyedcache
  • livesettings
  • satchmo_utils

After all this, I am finally able to start configuring Banjo!

Configuration

  • I uncommented django_evolution from banjo/__init__.py
  • When debugging, it is really helpful to comment out django_xmlrpc from banjo/__init__.py, and replace the line from banjo.blog.syndication import XMLRPC_METHODS in settings.py with XMLRPC_METHODS = None to eliminate a class of spurious error messages.
  • The default skin relies on an out-of-date version of yui from Yahoo APIs. If you want to use it you should change the link so that you get some CSS.

A couple things I did differently with my Banjo configuration: * I merged the Banjo settings.py with the one in my application so that none of my changes would be in the Banjo source. It was pretty straightforward. * I added this rule at the end of my urls.py so that all URLs I hadn’t already dealt with go to Banjo:
(r’^’, include(‘banjo.urls’)), * I then created my own skin using the Banjo base_root template as a starting point.

Skins

The docs on creating a skin are non-existent. Here are the steps I posted to the mailing list:

  1. I copied banjo/blog/templates/skins/default into myapp/templates/ skins/myskin
  2. I edited myapp/ templates/skins/myskin/CONFIG.json to have a different name.
  3. I added myapp/templates/skins to the SKIN_DIRS list in settings.py.
  4. I went into the admin interface and selected my skin.
  5. I then excised all the stuff that didn’t apply to my site and eliminated a couple of layers in the template inheritance hierarchy.

I found I couldn’t make all of the customizations I wanted in the skin, so I did have to edit a couple Banjo templates (_post_excerpt.html and view_post.html). I’m hoping to figure out a cleaner way in the future.

As you can see, I did eventually get everything working. It was less work than building from scratch such features as comment moderation, feed subscription, integrated search, scheduled post submission, caching, etc. And it’s higher quality as the Banjo developers included utilities I didn’t know about like Textile format and typogrify

Suggestions for Improvement

However, this process could be easier. Here are my suggestions for making Banjo more maintainable and more accessible to future users:

  • There should be a bias towards using released versions of projects. This makes it easier to install a version that works, and it makes it easier to monitor the libraries for security updates.
  • If a dependency project doesn’t have an active community, Banjo should consider folding that code into the Banjo core.
  • Even if a dependency project does have an active community, if it isn’t likely to get distributed by an OS package manager, Banjo should consider including the project with the banjo source in a libs subdirectory.
  • The maintainers should consider putting all the various Banjo and Satchmo libraries into a single package. In addition to making this easier to find and install, it also makes it easier to maintain. Currently they are scattered across various source repositories, issue trackers, and project home pages. This fragments an already small community.
  • The necessary Satchmo libraries should be factored out of Satchmo and put into the shared libraries package as soon as possible—it will only get harder with time. Banjo shouldn’t require the installation of a full blown shopping cart, and the Satchmo users will benefit from the larger community using their libraries. Satchmo and Banjo can then select which version of the libraries to depend on for each release, which will simplify both projects.
  • The project documentation can be improved with some of the information from this blog post.
  • Though the multi–site capabilities are excellent, I think the defaults can be improved so that it doesn’t get in the way of a simple single-site deployment. It doesn’t currently prevent single site deployment, but it makes it harder than it needs to be.

Conclusion

I think Banjo is pretty slick, and I hope to be able to contribute to the project. It has the potential of becoming a full featured, easy to install and yet easy to modify, blogging platform. I’m also glad I discovered Banjo because it introduced me to Satchmo, which looks like a mature Django shopping cart application which will likely come in handy some day.

My next project is going to involve testing django-cms to see if I should add it to my my web developer toolbox.

Blog, shopping cart, CMS—Django is quickly getting to where it can fulfill most of my client’s needs.

Pingbacks

Pingbacks are closed.

Comments

  1. fireant

    fireant on #

    your article/guide saved me a lot of work, thanks

  2. Richard

    Richard on #

    I'm glad you found this post helpful.

    It looks like http://getbanjo.com is down.

    The current code is available from Assembla:
    http://banjo.assembla.com

Comments are closed.