He creado dos entornos de python con virtualenv: /usr/local/pythonenv/BASELINE
y /usr/local/pythonenv/django1
. Ambos fueron creados con --no-site-packages. Instalé django en el entorno django1 con easy_install.mod_wsgi python no puede importar de la biblioteca estándar
Mi archivo wsgi.conf tiene esta línea para establecer el intérprete de Python:
WSGIPythonHome /usr/local/pythonenv/BASELINE
Mi archivo django.wsgi comienza así:
import site
site.addsitedir('/usr/local/pythonenv/django1/lib/python2.7/site-packages')
import os
import sys
Pero cuando trato de visitar mi sitio, obtiene un error 500, y httpd/error_log contiene:
[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
estoy perdido en cuanto a porqué el intérprete de Python no puede importar su ow n biblioteca estándar. Ni siquiera estoy seguro de cómo comprobar si httpd incluso está utilizando el intérprete en/usr/local/pythonenv/BASELINE, por lo que sería un buen comienzo.
Editar: Sin relación, pero estaba bastante desgarrado sobre si debería publicar esto aquí o en ServerFault. Asesoramiento en ese frente apreciado.
Editar: Así que pude obtener información de depuración gracias a http://code.google.com/p/modwsgi/wiki/DebuggingTechniques. He cambiado mi guión django.wsgi para contener
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]
Esto puso la información intérprete de Python en/var/log/httpd/error_log. La salida del error:
[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
Entonces sys.path y sys.executable apuntan a mi problema. Por algún motivo, sys.path está utilizando algunos archivos lib que no existen (BASELINE ni siquiera contiene un directorio lib64, y se creó con Python2.7), y sys.executable muestra que mod_wsgi aún ejecuta el valor predeterminado/usr/intérprete bin/python, no el intérprete en/usr/local/pythonenv/BASELINE/bin.
No estoy seguro de por qué este es el caso, pero al menos sé un poco más ahora.
EDITAR: Esto está resuelto, pero Django aún enumera "Python Executable:/usr/bin/python" aunque debería ser (y por lo que puedo decir, lo es, desde la versión de Python: 2.7.2) usando/usr/local/bin/python. ¿Esto es normal?
Sí, este es el problema. Pensé que había compilado mod_wsgi contra Python 2.7 porque ejecuté ./configure --with-python =/usr/local/bin/python y luego hice y realicé la instalación, pero esto no funcionó porque todavía tenía los objetos viejos sentado allí. Tenía que limpiar, luego seguir la secuencia de compilación. – sans