projet Django (apache, mod_wsgi) ne peuvent pas importer des packages d'espace de noms

Question

Lors de l'installation django-piston du repo bitbucket avec pépin, j'ai remarqué quelque chose de bizarre (de première ligne en retrait de la sortie):

$ 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 ne sera pas installer le piston __init__.py, indiquant que c'est parce que «piston» est spécifié comme l'un des namespace_packages dans le setup.py.

De plus, quand je regardais à l'intérieur du « django_piston-0.2.3rc1-nspkg.pth » fichier, je trouve cela, ce qui semble être une tentative de « paquets virtuels »:

# 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) 

Je peux voir ce qu'il fait ici; c'est en fait la création d'un "faux module", où le piston devrait être be, qui agrège essentiellement tous les sous-modules du piston.

Cela semble fonctionner correctement pour le travail en ligne de commande (je peux importer le piston du shell django [bien que sa repr soit <module 'piston' (built-in)>], et les choses semblent fonctionner correctement depuis runserver.), Mais mon projet, fonctionnant sur apache mod_wsgi , renvoie une erreur 500 sur chaque page, car il n'y a "aucun module nommé piston.handler". J'ai exclu les problèmes de chemin python; le répertoire site-packages est dans le chemin pour toutes les tentatives. Je ne sais pas d'autres raisons pour lesquelles il se comporterait comme ça, des idées?

Answer 1

Après avoir regardé un peu plus, j'ai découvert la réponse à the docs for mod_wsgi:

Comme une étape supplémentaire cependant, le fichier script WSGI décrit dans les instructions serait modifié pour superposer l'environnement virtuel pour l'application au-dessus de l'environnement de base. Cela serait fait en ajoutant au début du fichier script WSGI les éléments suivants:

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

Notez que dans ce cas, le chemin complet vers le répertoire «site-packages pour l'environnement virtuel doit être spécifié et pas seulement la racine de l'environnement virtuel. Utiliser 'site.addsitedir()' est un peu différent d'ajouter simplement le répertoire à 'sys.path' car la fonction ouvrira tous les fichiers '.pth' situés dans le répertoire et les traitera. Ceci est nécessaire pour s'assurer que tous les répertoires spéciaux liés aux œufs Python sont automatiquement ajoutés à 'sys.path'.

Ajout de l'appel site.addsitedir à mon script wsgi (à la place de annexant à sys.path, comme je l'avais fait) éclairci toutes les questions.