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?
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