python - digitalocean - uwsgi+Flask+virtualenv ImportError: ningún módulo llamado sitio
use a production wsgi server instead (8)
(Otras publicaciones en SO son similares, pero ninguna tiene la combinación específica de uwsgi + Flask + virtualenv) ( Esta es la más cercana )
Instalé uwsgi a través de apt-get. También probé pip install wsgi. Ambos me dieron el mismo problema.
Comando de prueba:
sudo uwsgi -s /tmp/uwsgi.sock -w myapp:app -H myvirtualenv
Resultado:
Python version: 2.7.4 (default, Apr 19, 2013, 18:35:44) [GCC 4.7.3]
Set PythonHome to myvirtualenv
ImportError: No module named site
De lo contrario, puedo ejecutar mi aplicación en el env virtual.
El camino a su entorno virtual es incorrecto. Esa es la razón de este error.
Estoy usando virtualenvwrapper y mis entornos virtuales están configurados en ~ / .virtualenvs. Así que en mi caso, la llamada uwsgi sería algo así como
sudo uwsgi -s /tmp/uwsgi.sock -w myapp:app -H ~/.virtualenvs/myapp
Espero que esto ayude la próxima vez que alguien venga a buscar este.
Gracias a Cody por señalarlo en los comentarios.
En mi caso, el problema fue la versión de python que uWSGI intentó usar.
Mi proyecto fue escrito en Python 3.4, pero no estaba especificando esto en la configuración de uWSGI. Así que uWSGI intentó usar python 2 e intentó importar módulos desde la carpeta lib / python2.7 dentro del virtualenv.
Así que recibí el error ''No hay módulo llamado sitio'', porque todos los módulos, incluido el módulo del sitio, estaban dentro de lib / python3.4, no lib / python2.7.
Para resolverlo, tuve que hacer dos cosas:
Instala el plugin python3 para uWSGI, con:
apt-get install uwsgi-plugin-python3Úsalo en el archivo de configuración .ini, con:
plugins = python34
Espero que esto ayude a alguien con el mismo problema en el futuro.
Según lo solicitado, aquí sigue mi archivo .ini:
[uwsgi]
base = /your/app/path
pythonpath = %(base)
module = your_module_name
callable = app #Here you put the name of the variable which holds your app inside your module
home = /your/virtualenv/path
plugins = python34
master = true
processes = 2
uid = www-data
gid = www-data
socket = /path/to/socket
chmod-socket = 660
die-on-term = true
logto = /var/log/uwsgi/%n.log
Encontré lo mismo y mi problema fue con la versión de python donde se estaba ejecutando uwsgi. uwsgi se estaba ejecutando en python2 pero mi ruta virtualenv python estaba configurada en python3. Esto creó el conflicto, siguió fallando en localizar el paquete del sitio instalado.
Verifique dos veces la versión de python en la que se está ejecutando uwsgi para que coincida con la configurada en su virtualenv.
Si su entorno virtual se está ejecutando en Python3, debe instalar uwsgi usando pip3, de lo contrario, la discrepancia de la versión creará este problema de importación
pip uninstall uwsgi
pip3 install uwsgi
Tuve el mismo problema antes. Mi problema es que tengo ambos python2.x y python3.x en mi sistema ubuntu, y quiero que mi proyecto se ejecute en un entorno virtual en el que está instalado el entorno python3. Cómo resolví este problema:
apt-get install python3-pip
pip3 instalar uWSGI
Eso es todo.
Tuve este problema cuando mi homebrew actualizó mi versión de Python a Python 3.7 y dejó de funcionar. Lo que me funcionó fue brew info python , que te mostrará todas las versiones disponibles de Python. Luego volví a Python 3.6.5 usando el brew switch python 3.6.5 .
Después de eso simplemente reinstalé mi uWSGI usando:
pip3 uninstall uwsgi
pip3 install uwsgi
Y eso lo resolvió. Si no está seguro de qué versión de Python estaba usando, brew info python muestra las fechas de instalación. Además, puede verificar usando la pip3 list si su uWSGI está instalado para la versión actual.
¡Espero que esto ayude!
Esto puede ser malo para la seguridad por varias razones. FUNCIONA PARA PRUEBAS. PERO REVISE LA SEGURIDAD ANTES DE USAR ESTA SOLUCIÓN EXACTA EN LA PRODUCCIÓN
Otra razón por la que este error puede ocurrir es por permisos relacionados Si usa un archivo .ini como se describe en el tutorial oficial de uWSGI para django , puede haber creado el archivo ini con un usuario y grupo que hace que el archivo sea inaccesible para el usuario que está ejecutando el proceso.
Verifique el propietario y los permisos para el archivo y la ruta del directorio en el que se encuentra. Use chown y chmod para establecer los permisos necesarios.
sudo chown -R www-data:www-data /srv
sudo chmod 0775 -R /srv
En mi caso, estaba usando un cuadro de vagrant para las pruebas y el usuario predeterminado es "vagrant" mientras que nginx usa los datos de www para el usuario y el grupo. He establecido el propietario de todos los archivos en el proyecto para el usuario y grupo de www-data y he agregado el usuario errante al grupo de www-data.
sudo gpasswd -a vagrant www-data
No estoy seguro si esto es una buena práctica de seguridad, así que trabajaré con el administrador de mi sistema cuando llegue el momento de ponerlo en producción. Pero para mi entorno de prueba funciona. De cualquier manera, los permisos serán algo que se debe observar de cerca para muchos de estos problemas.
Vea la respuesta de @JRajan primero.
Si está seguro de que solo desea suprimir el error y no resolver realmente el problema subyacente, haga clic con el mouse debajo.
Agregue
--no-sitea su comando ono-site=truea su archivo uwsgi.ini.