Michele Campeotto: Tag django

A little Django feature nobody tells you about

micampe — Sat, 06 Jan 2007 07:38:00 -0800

Recently i got involved in a new project which uses Django, so I started learning and using it. I won’t tell you here it merits as those have alread been described at lenght.

One of the features I like about Django are its pluggable applications: you can build a generic piece of code and that can easily be plugged in other’s sites to get some new functionality. Great examples of this are found in the django.contrib package, which include the already famous administrative interface, two comments systems, an authentication/authorization framework and more.

One problem you’ll soon find is that some of these are tied to be plugged at a fixed URL prefix. The auth system, for example, expects to be plugged in the /accounts/ directory and plugging it somewhere else leads to some more work for you. The easiest example is the @login_required decorator, which checks the user that is calling a view and, if it is not authenticated, it redirects to /accounts/login. If you have used a different URL prefix, you are forced to use the @user_passes_test decorator, which allows you to set the redirect URL.

Where is the problem? The problem is that those paths are explicitly hardocded in the views.

How to solve it? Dynamically build your URLs from your urlconf.

How do you do that? With django.core.urlresolvers.reverse()

That little boy helps you by giving you the URL path that would be called given a view and a set of parameters. Here is an example, suppose your urlconf has something like this:

urlpatterns = patterns('',
    (r'^/blog/(?P<year>\d{4})/(?P<month>\d{2})/(?P<day>\d{2})/(?P<slug>[-\w]+)/$',
        'dlog.blog.views.entry'),
)

you could create a function like this to get the URL of an entry:

    def get_absolute_url(self):
        return urlresolvers.reverse('dlog.blog.views.entry',
                kwargs={'year':self.pubdate.year,
                        'month':('%02d' % self.pubdate.month),
                        'day':('%02d' % self.pubdate.day),
                        'slug':self.slug})

when you then call an entry’s get_absolute_url() method, you’ll get the URL as urlconf expects it.

/blog/2007/01/06/your-slug-goes-here

I don’t know why this isn’t mentioned anywhere in the docs, I found it by hunting down the source code because I didn’t like hardcoding paths in my views.

I can understand it has some problems: it gives you only URLs relative to the root of the Django project, if you need an absolute URL or if you attached the site to a subdirectory of your domain, urlresolvers.reverse() is not enough, but I still think it should be advertised in the documentation.

One more thing, as everybody starting to use Django, I wrote a web log with it. But I haven’t replaced this one, I created a new one, but this time in Italian and that will be more personal and, hopefully, a real blog that I update it more often than monthly and I actually participate. So, if you can read Italian follow me on my new corner.

A tale of Pylons, Python and FastCGI on Dreamhost

micampe — Sun, 26 Nov 2006 08:01:00 -0800

Pylons is a WSGI based Python Web Framework that tries to combine the best ideas from other existing frameworks and does so by glueing togheter existing projects and allowing to swap its components at will and easily extend its capabilites with other WSGI components.

I will explain here how I installed it and a demo application on Dreamhost and how to avoid the single problem I had.

This procedure isn’t specific to either Dreamhost or Pylons, it can be used anywhere and for any WSGI compliant application if you don’t have root access to install new modules or if you want to keep the system wide installation clean and add modules just for a single user.

The installation procedure is quite easy and mostly automated, start by running these commands from your home directory on the remote shell:

mkdir bin
wget -P bin http://peak.telecommunity.com/dist/virtual-python.py
python2.4 bin/virtual-python

It’s important that you use python2.4 here, not just python.

This command will create some directories and symlinks on your home directory that will result in you little private Python environment, where you have the power to install new packages at will. To make the illusion more real, you should then add ~/bin in front of your $PATH, so that you can just type python in the shell and the interpreter used will be your private one instead of the global one.

export PATH="~/bin:$PATH"    # add this to ~/.bash_profile
wget -P bin http://peak.telecommunity.com/dist/ez_setup.py
python bin/ez_setup.py

This will install the easy_install script that you will use to install Pylons and other Python modules you can find on the Cheese Shop:

easy_install Pylons

This will install the Pylons framework and all its dependencies. To test the installation we will use the QuickWiki demo application:

easy_install QuickWiki

This will install the application and some more dependencies. The next step is creating the configuration file for the application:

paster make-config QuickWiki wiki.ini

In this file you only have to change the database URI, for this test we will use SQLite:

sqlalchemy.dburi = sqlite:///quickwiki.db

And setup the application to create the database:

paster setup-app wiki.ini

Then we need a script to start the application. Pylons, as every WSGI application can be deployed in a number of different ways, but the only one you can use on Dreamhost is FastCGI. At this point, every tutorial around the web will tell you to use flup and then there will be pain and hair pulling because you won’t understand why it’s not working (unless you ask Allan Saddi to check your setup, that is. Thank you Allan!).

The solution is to use the supposed to be obsolete fcgi.py script, so let’s install it:

wget -P lib/python2.4/site-packages http://svn.saddi.com/py-lib/trunk/fcgi.py

We said we needed a script, so put this in a file named server.fcgi in your web directory and make it executable:

#!/home/username/bin/python

from paste.deploy import loadapp
from fcgi import WSGIServer

app = loadapp('config:/home/username/www.yourdomain.net/wiki.ini')
server = WSGIServer(app)
server.run()

You will need to correct the paths here, as we need them to be absolute.

Now when you point at this file in a web browser you should see the QuickWiki FrontPage.

The problem with flup (as found by Allan itself) is that it takes too long to start and it seems that FastCGI on Dreamhost will wait for a maximum of 3 seconds. fcgi.py instead is simpler (doesn’t do thread pooling for example) and therefore faster to start. This means that when the server is under heavy load there could still be problems, but it has been pretty reliable.

The best solution to this problem would be SCGI support by Dreamhost, if you already are a customer, go vote for it!