2011-10-13 6 views
6

J'ai créé deux environnements python avec virtualenv: /usr/local/pythonenv/BASELINE et /usr/local/pythonenv/django1. Les deux ont été créés avec --no-site-packages. J'ai installé django dans l'environnement django1 avec easy_install.mod_wsgi python ne peut pas importer de la bibliothèque standard

Mon fichier wsgi.conf a cette ligne pour définir l'interpréteur Python:

WSGIPythonHome /usr/local/pythonenv/BASELINE 

Mon fichier django.wsgi commence comme:

import site 
site.addsitedir('/usr/local/pythonenv/django1/lib/python2.7/site-packages') 
import os 
import sys 

Mais lorsque je tente de visiter mon site, je obtenez une erreur 500, et httpd/error_log contient:

[error] Traceback (most recent call last): 
[error] File "/service/usr/local/django_apps/apache/django.wsgi", line 1, in ? 
[error]  import site 
[error] ImportError: No module named site 

Je suis perdu la raison pour laquelle l'interpréteur Python ne peut pas importer son OW n bibliothèque standard. Je ne sais même pas comment vérifier si httpd utilise même l'interpréteur dans/usr/local/pythonenv/BASELINE, ce serait donc un bon début. Edit: Sans rapport, mais j'étais assez déchiré de savoir si je devais publier ceci ici ou à ServerFault. Des conseils sur ce front appréciés.

Modifier: J'ai donc pu obtenir des informations de débogage grâce à http://code.google.com/p/modwsgi/wiki/DebuggingTechniques. J'ai changé mon script django.wsgi pour contenir

import sys 
def application(environ, start_response): 
    status = '200 OK' 
    output = 'Hello World!' 
    print >> environ['wsgi.errors'], sys.path 
    print >> environ['wsgi.errors'], sys.prefix 
    print >> environ['wsgi.errors'], sys.executable 

    response_headers = [('Content-type', 'text/plain'), ('Content-Length', str(len(output)))] 
    start_response(status, response_headers) 
    return [output] 

Cela a mis l'information d'interpréteur Python dans/var/log/httpd/error_log. La sortie d'erreur:

[error] ['/usr/local/pythonenv/BASELINE/lib64/python24.zip',  '/usr/local/pythonenv/BASELINE/lib64/python2.4/', '/usr/local/pythonenv/BASELINE/lib64/python2.4/plat-linux2', '/usr/local/pythonenv/BASELINE/lib64/python2.4/lib-tk', '/usr/local/pythonenv/BASELINE/lib64/python2.4/lib-dynload'] 
[error] /usr/local/pythonenv/BASELINE 
[error] /usr/bin/python 

Ainsi sys.path et sys.executable pointent vers mon problème. Pour une raison quelconque, sys.path utilise des fichiers lib qui n'existent pas (BASELINE ne contient même pas de répertoire lib64, et il a été créé avec Python2.7), et sys.executable montre que mod_wsgi utilise toujours la valeur par défaut/usr/interprète bin/python, pas l'interpréteur dans/usr/local/pythonenv/BASELINE/bin.

Je ne sais pas pourquoi c'est le cas, mais au moins je sais un peu plus maintenant. EDIT: Ceci est résolu, mais Django liste toujours "Python Executable:/usr/bin/python" même s'il devrait l'être (et pour autant que je sache, il l'est, depuis Python Version: 2.7.2) en utilisant/usr/local/bin/python. Est-ce normal?

Répondre

4

Votre mod_wsgi n'est probablement pas compilé avec Python 2.7. Vous ne pouvez pas utiliser virtualenv pour une version Python avec mod_wsgi compilé avec une version différente de Python.

Lire de:

http://code.google.com/p/modwsgi/wiki/CheckingYourInstallation#Python_Shared_Library

et faire des vérifications dans ce document.

+1

Oui, c'était le problème. Je pensais que j'avais compilé mod_wsgi contre Python 2.7 parce que j'ai couru ./configure --with-python =/usr/local/bin/python et ensuite j'ai fait make et make install, mais cela n'a pas fonctionné parce que j'avais les anciens objets encore assis là. Je devais nettoyer, puis passer à travers la séquence de construction. – sans

Questions connexes