WSGI and mod_python

I've shown how to run web applications within the simple environment provided by wsgiref, but what about launching something on a live site? The WSGI wiki lists multiple servers that support WSGI, including (but not limited to) CherryPy, python-fastcgi, and Paste; chances are, if you're using a framework, your production choices will be very easy.

I've decided to use one of the simpler approaches: mod_python coupled with a modified version of wsgi_handler.py. Nicolas Borko wrote this script based on his reading of the PEP. It allows you to publish WSGI applications under Apache easily.

Consult the mod_python documentation for help installing mod_python in your environment, but certainly in the case of K/Ubuntu, the process is straightforward:

The handler needs to be accessible by mod_python before you go any further. You have two choices: either append the location of wsgi_handler.py to the Python path, or copy the file into site-packages (again, mine is /usr/lib/python2.4/site-packages/). For the moment, I've opted to copy. Once wsgi_handler is in place, create a configuration file (mod_python.conf) in the directory /etc/apache2/mods-enabled (or the location of module configuration files for your Apache setup) and insert at least some basic configuration:

This configuration directs any requests to the test directory of my webroot (/var/www) with a .py extension to the wsgi_handler. The WSGI application I want to run is once again in the script test1.py (with the function simple_app). I've placed this file in /var/python (and the configuration adds this directory to the Python path). Restart Apache httpd and, with any luck, you'll be able to browse to http://localhost/test/test.py.

My slightly modified version of wsgi_handler provides the ability to specify just a script in the mod_python configuration, rather than a script and function. This allows a more powerful configuration:

Rather than a directory, this setting configures a location relative to the web server root. I've used SetHandler, which does not require the file extension. Also, the PythonOption now includes only a reference to the test1.py script. If you add these directives to your mod_python configuration file, you can use the URL http://localhost/test/foo/simple_app, which means you'll now be able to add more than one WSGI application to the script. Whether this is a good idea in production code is debatable, but it's certainly useful for development.

Conclusion

WSGI exposes one of the simplest APIs I've seen in a while, and I believe that very simplicity underlies its power. As a framework or utility developer, the middleware concept is an attractive approach to layering features without having to bolt everything in at the lowest level, while an application developer keen on "keeping it simple, stupid" can work with an extremely basic interface. With a growing number of the higher-level frameworks supporting WSGI, and with the addition of the wsgiref module to Python 2.5, you can easily roll WSGI into your own projects--you may even be using it already without knowing it. Hopefully this article has pointed you in a few directions for further reading and experimentation of your own.