Question

When installing django-piston from the bitbucket repo with pip, I noticed something weird (first indented line of the output):

$ pip install hg+http://bitbucket.org/jespern/django-piston
Downloading/unpacking hg+http://bitbucket.org/jespern/django-piston
Cloning Mercurial repository http://bitbucket.org/jespern/django-piston to /tmp/pip-v1h8Sh-build
Running setup.py egg_info for package from hg+http://bitbucket.org/jespern/django-piston
Installing collected packages: django-piston
Running setup.py install for django-piston
    Skipping installation of [venv]/lib/python2.6/site-packages/piston/__init__.py (namespace package)
    Installing [venv]/lib/python2.6/site-packages/django_piston-0.2.3rc1-py2.6-nspkg.pth
Successfully installed django-piston
Cleaning up

Pip won’t install piston’s __init__.py, indicating that this is because ‘piston’ is specified as one of the namespace_packages in the setup.py.

Further, when I looked inside the “django_piston-0.2.3rc1-nspkg.pth” file, I find this, what seems to be an attempt at “virtual packages”:

# File: [virtualenv]/lib/python2.6/site-packages/django_piston-0.2.3rc1-py2.6-nspkg.pth
# Originally all on one line; broken apart here for readability.

import sys,new,os;
p = os.path.join(sys._getframe(1).f_locals['sitedir'], *('piston',));
ie = os.path.exists(os.path.join(p,'__init__.py'));
m = not ie and sys.modules.setdefault('piston',new.module('piston'));
mp = (m or []) and m.__dict__.setdefault('__path__',[]);
(p not in mp) and mp.append(p)

I can see what it’s doing here; it’s basically creating a “fake module”, where piston should be, which essentially aggregates all of piston’s sub-modules.

This seems to work fine for command-line work (I can import piston from the django shell [though its repr is <module 'piston' (built-in)>], and things seem to work fine from runserver.), but my project, running on apache mod_wsgi, throws a 500 error on every page, because there’s “No module named piston.handler”.

I’ve ruled out python path issues; the site-packages dir is in the path for all attempts. I don’t know any other reasons why it would behave like this, any ideas?

Answer 1

After looking some more, I discovered the answer in the docs for mod_wsgi:

As an additional step however, the WSGI script file described in the instructions would be modified to overlay the virtual environment for the application on top of the baseline environment. This would be done by adding at the very start of the WSGI script file the following:

import site
site.addsitedir('/usr/local/pythonenv/PYLONS-1/lib/python2.5/site-packages')

Note that in this case the full path to the ‘site-packages’ directory for the virtual environment needs to be specified and not just the root of the virtual environment.

Using ‘site.addsitedir()’ is a bit different to simply adding the directory to ‘sys.path’ as the function will open up any ‘.pth’ files located in the directory and process them. This is necessary to ensure that any special directories related to Python eggs are automatically added to ‘sys.path’.

Adding the site.addsitedir call to my wsgi script (in place of appending to sys.path, as I had been doing) cleared up all the issues.