More on mod_wsgi issues

When you add wsgi to Apache it is so you can run Python on Apache. Thus you need, at a minimum, Python and Apache.

Python

If you use a utility such as virtualenv to compartmentalize several domain development environments on one server account, installing mod_wsgi may not and probably will not be associated with the correct Python library. Will not, that is, unless you explicitly point it out in the installation process. Be sure to plan in advance which Python install you are developing for, and be sure to flag it when installing mod_wsgi:

./configure --with-python=/home/django/domains/mydomain.com/bin/python2.5* ***

*** UPDATE (1/31/10): Please read the helpful comment and link from Graham Dumpleton, author of mod_wsgi, below. Per his direction, it is best to install mod_wsgi against the complete base Python installation and add references to the virtual environments from your Apache config or from the WSGI script file. Thanks for taking the time to clarify, and for making mod_wsgi available for general use.

That said, there are many ways to install mod_wsgi, from manual to managed by aptitude, get-apt or the like. The downside to using a managed install is the dependency on the vintage of their managed version. At last check, the aptitude repository of mod_wsgi is still at 1.3 while the current stable version on googlecode is 2.8. Thus, you may want to look into another method, perhaps a manual installation.

Apache

When manually installing mod_wsgi, be sure you have the appropriate development library for apache, in the case of ubuntu hardy heron, apache2_threaded_dev will allow you to install mod_wsgi. Furthermore, if you are using aptitude to install apache2_threaded_dev, go ahead and update the distro as a whole first by running sudo aptitude update. If you do not, you may find the install doesn't work, and there will be no indication as to what went wrong.

Finally, with these measures in place, try ./configure with the appropriate flags and see if you can get the correct library in place. Good luck.

*your location will be different from this example

Virtualenv vs Virtual-Python

If you harbor multiple versions of Python, as is usually a good idea, you can go at least two routes:

1. Virtualenv
2. Virtual-Python

Both organize your all-important PYTHONPATH environment variable and keep your preferred python executable at the ready. This in turn makes module add-ons, test projects and installations easy.

On that note, Easy_install recommends virtual-python.py as a quick way to keep organized. It is indeed easy to set up and concise as well.

Another option, the one I use incidentally, is virtualenv. Once installed, all you need to do to switch active versions is activate it via the command line.

In a newly created virtualenv there will be a bin/activate shell script, or a Scripts/activate.bat batch file on Windows.

On Posix systems you can do:

$ source bin/activate

Even better than that is Doug Hellmann's virtualenvwrapper which, as he describes, allows you to set a working python environment with a single command. It's easy to set up as well, just a couple of lines into your bash script and bombs away, your virtualenv is wrapped.

With these options, you can initiate new projects and test new python libraries without any conflicts or misgivings. Try it out sometime. What have you got to lose?