My previous setup worked until I wanted to add another Django instance and then it didn’t work, because I had two WSGIScriptAlias entries under different URLs but it would launch whichever app it wanted to regardless of the URL. A little searching suggested that it had to do with mod_wsgi process pools. I eventually ended up with something like this:
WSGIPythonHome /www/python/pypi.venv
WSGIPythonPath /www/python/django
WSGIPassAuthorization On
WSGISocketPrefix /var/run/wsgi
<VirtualHost *:80>
...
DocumentRoot /www/python
WSGIDaemonProcess djangoplayground_wsgi user=apache python-path=/www/python/django
WSGIScriptAlias /djangoplayground /www/python/django/djangoplayground/wsgi.py
<Location /djangoplayground>
WSGIProcessGroup djangoplayground_wsgi
</Location>
WSGIDaemonProcess djangopypi_wsgi user=apache python-path=/www/python/django
WSGIScriptAlias /djangopypi /www/python/django/djangopypisite/wsgi.py
<Location /djangopypi>
WSGIProcessGroup djangopypi_wsgi
</Location>
</VirtualHost>
The underlying problem here is actually likely to be the wsgi.py file generated by Django 1.4. In prior versions of Django they used:
os.environ[‘DJANGO_SETTINGS_MODULE’] = ‘mysite.settings’
From 1.4 they use:
os.environ.setdefault(‘DJANGO_SETTINGS_MODULE’, ‘mysite.settings’)
This change will break mod_wsgi where multiple Django sites are being run in separate sub interpreters of the same process.
This is because setting os.environ actually sets the process wide environment variable and so when they second site starts up, it sees the environment variable set by the first and use of setdefault() means it isn’t overridden.
You can either change back to assignment rather than setdefault(), or delegate each site to a separate mod_wsgi daemon process group.
Thanks, you saved my hair!