Django, mod_wsgi and virtual env

Question

I'm setting up Django with apache, mod_wsgi, virtual env

I have a virtual env that I want to use here: [Missleading name - long story!] /home/andy/Dev/python/async-mongo/

I downloaded mod_wsgi and compiled it with virtual_env as root

./configure --with-python=/home/andy/Dev/python/async-mongo/bin/python

I ran as root:

make install

I setup WSGIPythonHome & Path in http.conf

WSGIPythonHome /home/andy/dev/python/async-mongo/
WSGIPythonPath /home/andy/dev/python/async-mongo/lib/python2.6/site-packages
LoadModule wsgi_module /usr/lib/apache2/modules/mod_wsgi.so

I think I followed the instructions at http://code.google.com/p/modwsgi/wiki/VirtualEnvironments

When I run the 'Hello World' app it works

def application(environ, start_response):
    status = '200 OK'
    output = 'Hello World!'
    response_headers = [('Content-type', 'text/plain'),
                        ('Content-Length', str(len(output)))]
    start_response(status, response_headers)

    return [output]

When I try to import a module it fails:

import sys; raise Exception(sys.path)
def application(environ, start_response):
    status = '200 OK'
    output = 'Hello World!'
    response_headers = [('Content-type', 'text/plain'),
                        ('Content-Length', str(len(output)))]
    start_response(status, response_headers)
    print >> sys.stderr, 'sys.prefix = %s' % repr(sys.prefix)
    print >> sys.stderr, 'sys.path = %s' % repr(sys.path)
    return [output]

The error I see in the apache logs is:

[Fri Mar 30 15:09:53 2012] [notice] Apache/2.2.20 (Ubuntu) mod_wsgi/3.3 Python/2.6.7 configured -- resuming normal operations

........

Exception: ['/home/andy/dev/python/async-mongo', '/home/andy/dev/python/async-mongo/lib/python2.6/site-packages/setuptools-0.6c11-py2.6.egg', '/home/andy/dev/python/async-mongo/lib/python2.6/site-packages/pip-1.0.2-py2.6.egg', '/home/andy/dev/python/async-mongo/lib/python2.6/site-packages/txmongo-0.3-py2.6-linux-i686.egg', '/home/andy/dev/python/async-mongo/lib/python2.6', '/home/andy/dev/python/async-mongo/lib/python2.6/plat-linux2', '/home/andy/dev/python/async-mongo/lib/python2.6/lib-tk', '/home/andy/dev/python/async-mongo/lib/python2.6/lib-old', '/home/andy/dev/python/async-mongo/lib/python2.6/lib-dynload', '/usr/lib/python2.6', '/usr/lib/python2.6/plat-linux2', '/usr/lib/python2.6/lib-tk', '/home/andy/dev/python/async-mongo/lib/python2.6/site-packages']

I am guessing that somewhere somehow I am still referencing the old system level python but I can not understand where. How can I fix this?

Surely it's failing because you're explicitly raising an exception? — Daniel Roseman, Mar 30 '12 at 14:27
@DanielRoseman: his problem is not the exception, it's the sys.path he is inspecting through the exception message. — Paulo Scardine, Mar 30 '12 at 14:43
@PauloScardine So you say, but I'd like to hear from him that he hasn't perhaps mistaken the `;` for some sort of try/except handling. — Daniel Roseman, Mar 30 '12 at 14:50
You would not normally compile mod_wsgi against the virtual environment. You would still compile it against the main Python that the virtual environment is based off. If setting WSGIPythonHome you would not need to also set WSGIPythonPath to site-packages of same installation, it should work without doing that. — Graham Dumpleton, Mar 30 '12 at 22:18

score 3 · Accepted Answer · answered Mar 30 '12 at 14:36

3

You are raising an exception here:

import sys; raise Exception(sys.path)

answered Mar 30 '12 at 14:36

alan

4,752
21
30

Oh. Oops. I see Daniel Roseman already said this in comments. Sorry for the repetition. – alan Mar 30 '12 at 14:37
I think he is raising the exception only to inspect sys.path at runtime. – Paulo Scardine Mar 30 '12 at 14:40
oops - I put that in to inspect the runtime because it wasn't working and completely forgot it - sorry I'm being an idiot. – andy boot Mar 30 '12 at 15:39

Paulo Scardine · Answer 2 · 2012-03-30T14:48:07.653

The place to fiddle with sys.path is at your_application.wsgi. I don't think compiling mod_wsgi pointing to a virtualenv python binary is a good idea, the whole point of virtualenv is flexibility (having several versions of django playing nice in the same machine, for example).

My take on django, apache, wsgi and virtualenv is a my_application.wsgi file like this:

import os
import sys
import site

# Backup sys.path
prev_sys_path = list(sys.path)
# Add virtual environment to site directories:
site.addsitedir('/var/lib/python-environments/my_env/lib/python2.6/site-packages')

# settings.py sitting at /path/to/apps/my_application
os.environ['DJANGO_SETTINGS_MODULE'] = 'my_application.settings'
sys.path.append('/path/to/apps')

# start the trick
sys.path.extend([
   '/var/lib/python-environments/my_env/lib/python2.6/site-packages',
   '/var/lib/python-environments/my_env/lib/python2.6/site-packages/django/contrib/admindocs',
])
# Reorder syspath
new_sys_path = [p for p in sys.path if p not in prev_sys_path]
for item in new_sys_path:
    sys.path.remove(item)
# Make sure virtual env is first
sys.path[:0] = new_sys_path

import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()

Django, mod_wsgi and virtual env

2 Answers2

Linked