Deploying the web site describes a process for setting up a web server to run willshake. I use it to ship willshake.net, and it’ll work on your computer, too. So what’s this all about?

This is about an alternative: an ad-hoc server that you can create on the fly without affecting the rest of your system, which may be preferable in some situations.

An ad-hoc server is particularly useful for development. You can run it from any directory, i.e. wherever you have a copy of the project. And it doesn’t require any messing with the permissions of that directory (to give Apache access). You also don’t have to mess with your Apache configuration, which is nice if you happen to be using it for anything else. And it’s easy to run more than one copy of the site at a time (on different port numbers), which can be useful for comparing versions.

It’s also useful for pre-rendering the site, since you can create and destroy it automatically.

If you have mod_wsgi-express installed, then you can run the web site with a little script. The environment variables that are assumed by the configuration files need to be set as actual environment variables. Setting NO_WSGI is important here, since to prevent “our” WSGI configuration from conflicting with the one that express creates.

export SITE_ROOT=`pwd`
export DOCUMENT_ROOT="${SITE_ROOT}/site"
export DOMAIN=florizel
export NO_WSGI=true

mod_wsgi-express start-server 'server/getflow/getflow.wsgi' \
				 <<mod wsgi express options>>
				 --working-directory 'site' \
				 --document-root 'site' \
				 --log-to-terminal \
				 $*

This will start a new Apache server on port 8000, which should be fine for testing. log-to-terminal is a useful development option, but not necessary. The final $* allows you to pass additional options when you call the script.

Most of the beauty of “express” is the fact that it generates a working Apache configuration for you. But you can also include your own customizations.

--include-file 'server/httpd.conf' \

To make the ad-hoc environment as close as possible to other environments, the base configuration is included.

Note that these rules are themselves added to the base Apache configuration that mod_wsgi-express creates. When you start the server, you can see its location, which will be something like /tmp/mod_wsgi-localhost:8000:1000/.

A convenient option, especially for development, specifies that the site should be restarted automatically whenever the Python code changes.

--reload-on-changes \

This does not apply to the httpd.conf. When that changes, the site needs to be restarted.

mod_wsgi-express has an option for compressing responses.

--compress-responses \

The web performance configuration already tells what types should be compressed. But this option is needed with express because otherwise the deflate module it not loaded at all.

You can ship everything you need. Once the server has express installed, you can deliver everything that’s needed just by sending files. You don’t need to do any external configuration.

A corollary to that is, you can be agnostic of the location of things, since express generates the Apache configuration for you. I don’t think there’s any way to do that when using a plain Apache configuration. This makes it easy to use the same scripts in both development and production.

Graham Dumpleton, the creator of mod_wsgi and mod_wsgi-express, says that the latter is suitable for production use, and I used it in production for several months. A few factors keep me from continuing to use it in production.