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

MAMP with mod_wsgi

Once you get a database set up, sqlite or otherwise, you can use it with Django applications. You can serve Django directly from a command line or through Apache. In either case you will need Django to be installed. From a command line, simply run the django server and browse to it:

django-admin.py runserver

If your production server is going to be Apache, your best bet is to run Django under Apache locally. To do this you need a helper library for Apache to use. The de facto solution is mod_wsgi.

mod_wsgi

To get started with mod_wsgi, typically you download mod_wsgi from Graham Dumpleton's Google Code repository, you go to your command line, you untar it, you configure it, you make it and you make install it. This makes the code library available to wsgi-enabled services, in effect allowing you to run Django on Apache.

When you make install mod_wsgi, it places the libraries in your /lib directory. Then it links to your Apache directory where OSX keeps it, /usr/libexec/apache2. Installation includes automatic detection, or you can use some optional flags to specify resource paths, detailed in the wsgi installation guidelines.

Now your OSX Apache has modwsgi installed, but the Apache version in MAMP does not. To verify this, try making a Django app and serving it via MAMP. First, make a new django app in an appropriate directory:

django-admin.py startproject myproject

Next, open and modify the config for your MAMP Apache app, located in /Applications/Mamp/conf/apache/httpd.conf. For that matter, have a look at what your OSX Apache instance has in its config file. It is private/etc/apache2/httpd.conf. Searching for wsgi in this file yields:

LoadModule wsgi_module libexec/apache2/mod_wsgi.so

Looks good even if the relative directory location may be an issue. Insert this info into the MAMP httpd.conf and test it. Actually, there is no need because it will not work. This is due to the structure of MAMP and its proprietary use of Apache. Unlike a full install of Apache, the folders in MAMP have a different structure and are optimized to run modularly. Consequently, you cannot append a flag to your configure command in this manner:

./configure --with-apxs=/usr/sbin/apxs2-worker

because the structure available to Apache is not in MAMP, so detection will fail.

This leaves a couple of options. Either reconstruct some of the MAMP Apache folders so detection will succeed or look for another solution. Considering the evident lack of general success from many Google searches, I am letting this fish off the hook. Feel free to leave a comment if you know a way to make it work.

As a final consideration, mod_python appears to be a lot quicker to set up with MAMP. That could be a candidate if you are in a pinch. Otherwise, if serving Python via Apache is your goal, I recommend using the resources included with OS X and skipping MAMP altogether.

Apache DocumentRoot in Python and Django

Be very deliberate in your overall architecture when setting up new django projects. The directory dependencies resulting from an apache-nginx-python-django server configuration can make your path dependencies very complicated.

Generally put, being indiscriminate in your setup now will result in extreme challenges to resource deployment later on.

Here are some working methods that can greatly complicate your setup:

• Hosting several modules on one URL
• Having only one virtual host for many projects
  
• Hosting several modules on one server account
• Setting Python gateway modules off the root of your URL
• Using Python server.py-type gateways in addition to ordinary http gateways

Here are some ways to simplify your paths:

• Set up several virtual hosts
  
• Host only one Django project per URL (or as few as you can manage)
  
• Clearly structure your resources to discourage any overlap on your VPS or dedicated server
• Consider the trade-offs between a complex rig of sites and resources and several simple unrelated server environments. There's really no need to attempt the most complex possible solution unless that's your bag.

The nice thing about Python and Django is that they can handle either direction. There's a way to work everything out however you prefer, and the choice is yours to make.

That said, remember also that it is nice when projects just work without a lot of complex troubleshooting or traffic control.

Here is an example of a moderately complex configuration with a mixed bag of pros and cons.