2011-10-13 11 views
6

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?

Respuesta

4

Su mod_wsgi probablemente no está compilado contra Python 2.7. No puede usar un virtualenv para una versión de Python con mod_wsgi compilado contra una versión de Python diferente.

Leer de:

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

y hacer controles en ese documento.

+1

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

Cuestiones relacionadas