Tim Child

It was just announced that Django 1.2 will be released on May 17th, which is in 3 days time.

Been waiting a while for this one to go to production release so I am really glad. The new messages framework looks much better, and I also love the date i18n features – something that really helps on a project at Cantemo where we have to deal with ISO formatted datetimes.

Now the users will be able to choose how their dates are displayed on individual systems.

There is a lot of interesting information about creating plugin architectures using Python all over the web, but its in fairly disparate places. This is an overview of the documentation that I found as of April 2010.

Firstly Dr André Roberge has some very interesting posts, as well as a talk at PyCon 2009 on Blip.tv entitled Plugins and monkeypatching: increasing flexibility, dealing with inflexibility. He is also the author of Crunchy which uses a plugin system. He goes on to write about his experiences in creating a plugin architecture on his blog, over 6 parts starting here on part 1.

Marty Alchin, the author of Pro Django has an interesting couple of pages in that same book about creating a simple plugin system, and the snippet of code is on djangosnippets.com. He also has an excellent blog post about implementing a plugin architecture, it also talks about Django but is fairly non-specific.

William E. Hart over 2009-2010 has also been researching Python Plugin Frameworks, his overview is on his blog and he is also the author of the PyUtilib Component Architecture. This was very recently released and so hasn’t gathered much momentum as of this post but looks very promising indeed.

Zope. The big one is the Zope Component Architecture. I must admit, that looking into it I think its overkill, I don’t like the configuration utility or the overhead it introduces – just to use it requires a lot of extra Zope modules. However google for it if you are interested in learning further.

Yapsy. Yapsy is interesting, looks extremely lightweight, has been around for a few years, is currently on version 1.7 and serves as a good starting point. It has no external dependancies.

SprinklesPy. SprinklesPy is also very lightweight but I am not sure that development is active on it (2006 was the last mention of it being used that I found), or that it has anyone in the community using it (a benefit I believe if you are implementing a system that you are not creating yourself.)

Trac is the one component architecture that frequently gets mentioned, and it has a very decent user base. However, ripping the plugin system out might be more work than is reasonable.

Examples of Plugin use in the wild:

• http://code.google.com/p/oohembed

Other interesting links:

• http://www.charlesleifer.com/blog/looking-registration-patterns-django/
• Stackoverflow thread on minimal plugin architectures
• http://live.gnome.org/Gedit/PythonPluginHowTo

It is clear to me that there is no correct way of implementing plugins and you have to pick based upon the needs of your project, but this should serve as a good starting point. I will add and update this post as my knowledge grows.

I am normally using Debian, Ubuntu or even Suse for deploying Django, but a recent customer needed to deploy on Red Hat Enterprise Server 5.

We decided beforehand to test deployment on RHEL5 and also on CentOS 5.4 and so these instructions should work for both environments. NginX will be used as the webserver.

The first thing I like to do is to upgrade the repository and add EPEL. This wasn’t needed I found on the RedHat box I was using, but was needed on CentOS but your mileage might vary. It should be noted that we made the system as up to date as possible with patches and yum updates.

I won’t be covering the database setup, it is assumed that this is already setup and done. I also won’t be covering the actually placing of the Django application anywhere.

Python 2.4 ships with both RHEL5 and CentOS 5 and is needed for the packaging environment YUM so I would advise not to replace it but just compile and install 2.5.5 (or 2.6) next to it.

Now we need to build and install NginX. I choose this primarily because of my experience with it, (I have used Apache2 a lot but its archaic ) and because of its speed.

There is a decent RedHat init.d script here: http://wiki.nginx.org/RedHatNginxInitScript, but remember that I have changed the installation location above so you will need to change the location in that script of nginx from /usr/sbin/nginx to /usr/local/sbin/nginx

You will also need a nginx.conf configuration script for /etc/nginx/ or you could roll your own using sites-available, sites-enabled pattern. I will attach the script soon.

Now with Python 2.5 installed we can install Django and other requirements:

I am using easy_install here as that is the most widely used tool, but pip with a requirements file is a better solution.

Now we need a database adapter. I am using PostgreSQL 8.4.2, if you are using MySQL, Oracle or some other database you will need to follow the recommended route for the Python adapter.

Change the location of pg_config:

And now install:

Then you need to install your application. This is really specific to your needs. I choose to install the files in /opt/cantemo/application-name as that is specific to our solutions, but RedHat style might mean that you wish to install somewhere else.

Lastly you will want to have your application start easily and also make sure that it starts if the machine ever reboots. To do this I am going to install the start-stop-daemon that is used on Debian based Linux distros on Redhat. I read some threads that it will but there is no ETA on that.

You should download the initd script for Django from http://code.djangoproject.com/wiki/InitdScriptForLinux. Change the RUN_AS user to the user on RedHat that you are going to use for running Nginx. By default this is apache.

Lastly make sure that your application directories have the correct user permissions but you should be able to start everything by issuing the following commands:

Eric Florenzano posted a nice tutorial on deploying django using FastCGI so also check that out, but I didn’t have much luck with daemontools on CentOS, and didn’t bother trying on RedHat. I suggest instead using start-stop-daemon. Check it out for other hints and tips though, particularly on prefork vs. threaded, pip, and more nginx configuration tips.

Here is a simple decorator that isn’t mentioned properly in the Django documentation.

It basically checks to see if the user is logged in and has is_staff before allowing a user access to the view. Use like you would the normal
@login_required decorator.

The built in admin pages that you get in Django can be useful, but they particularly become useful once you start to add a lot more functionality to them.

For instance the Django’s User authentication system (which lives in django.contrib.auth ) is widely used, and quite often you need to extend the user’s profile by using AUTH_PROFILE_MODULE and a separate model. But having a separate Admin screen for this is kind of pointless.

In the admin.py file for your model which provides extra information (in my example it is called UserProfile just do the following:

Simple once you know how.

Had an interesting little problem with gcc and python today on OS X 10.6.

Basically I was trying to use graphviz and pygraphviz, and installing from source I got messages like this:

This pointed to two problems I found:

1. MacOSX10.4u.sdk being used
2. “-Wno-long-double” being passed to gcc

Obviously I am on 10.6 and even though I do have that SDK installed it is the incorrect version. On some Xcode installations you won’t have it.

The remedy was to change the following file:

After backing up change all the instances of MacOSX10.4u.sdk to MacOSX10.6.sdk and then remove the flag -Wno-long-double

Then you should be able to compile from a normal python setup. For good measure I test easy_install as well and that worked smoothly..

So what do you do if you require a django setting in your templates, much like we have MEDIA_URL today?

Well there are use cases for this, (if you are in doubt have a look at the original ticket for adding MEDIA_URL to django ).

The easiest way that I have found so far is to write a context processor. For example in my settings I might have JAVASCRIPT_URL (which in my real life code changes depending on whether I am running in debug, test or from a CDN):

Now from here I would like to make this available in my templates. Create a new python file that is somewhere on your python path (Under my project, I create a utils directory and then put a file context_processors.py in there. Don’t forget __init__.py should live in that directory as well).

In the context_processors.py file simply put

In your settings.py file you might already have a reference to TEMPLATE_CONTEXT_PROCESSORS if not then add it like so:

And thats about it. From there on in you will be able to use JAVASCRIPT_URL like MEDIA_URL:

I am always forgetting about the stringformatting tag in Django’s templating language. For instance for leading zeros:

This will always put a leading zero.

Just came across an interesting problem with the contenttypes contributed application and the test framework.

If you are using fixtures in the test frame work you might find that the database gets out of date as you are working on it, particularly if you are creating new models all the time.

To get around this you need to regenerate the contenttypes database. If you depend on this, the following steps could give you problems so make sure that you back up your data (dumpdata) beforehand.

So first off drop the database:

If the database has foreign key dependancies on contenttypes you will not be able to reset it like that. Use a database administration tool and drop cascade on the django_content_type table instead.

Then sync the database to create a new contenttypes table:

Now you are ready to dumpdata into a fixture:

This post is a work in progress is now working I am glad to say. I have been working on a django site which needs two models updated for one post. It is actually using models very close to that on django-forums and I have created a forms.py file:

And then in my views (after importing in the correct models):

Now the bit that is in progress is the returning part of dealing with the form data being bound, but I am going to write a custom handler. This is obviously going to be much easier to handle than an update, which I will have to deal with at a point.

The form HTML looks like this btw: