web-dev-qa-db-fra.com

uwsgi + Flask + virtualenv ImportError: aucun module nommé site

(Les autres articles sur SO sont similaires, mais aucun n'a la combinaison spécifique uwsgi + Flask + virtualenv) ( Celui-ci est le plus proche )

J'ai installé uwsgi via apt-get. J'ai aussi essayé d'installer pip wsgi. Les deux m'ont donné le même problème.

Commande de test:

Sudo uwsgi -s /tmp/uwsgi.sock -w myapp:app -H myvirtualenv

Résultat:

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

Je peux sinon exécuter mon application dans l'environnement virtuel. 

pythonflaskvirtualenvuwsgi
17
010110110101

Voir la réponse de @JRajan en premier.

Si vous êtes sûr de vouloir simplement supprimer l'erreur et non pas réellement résoudre le problème sous-jacent, passez la souris ci-dessous.

Ajoutez --no-site à votre commande ou no-site=true à votre fichier uwsgi.ini. 

20
hughes

Le chemin d'accès à votre environnement virtuel est incorrect. C'est la raison de cette erreur.

J'utilise virtualenvwrapper et mes environnements virtuels sont définis sur ~/.virtualenvs. Donc, dans mon cas, l’appel uwsgi ressemblerait à quelque chose comme:

Sudo uwsgi -s /tmp/uwsgi.sock -w myapp:app -H ~/.virtualenvs/myapp

J'espère que cela aidera la prochaine fois que quelqu'un viendra chercher celui-ci.

Merci à Cody pour l'avoir signalé dans les commentaires.

23
JRajan

Dans mon cas, le problème était la version python que uWSGI avait essayé d’utiliser.

Mon projet a été écrit en python 3.4, mais je ne le spécifiais pas dans la configuration de uWSGI. Donc, uWSGI a essayé d’utiliser python 2 et d’importer des modules à partir du dossier lib/python2.7 dans virtualenv.

J'ai donc reçu l'erreur 'Aucun module nommé site', car tous les modules, y compris le module de site, se trouvaient dans lib/python3.4, pas lib/python2.7.

Pour le résoudre, je devais faire deux choses:

  • Installez le plugin python3 pour uWSGI, avec:
    apt-get install uwsgi-plugin-python3

  • Utilisez-le dans le fichier de configuration .ini avec:
    plugins = python34

J'espère que cela aidera quelqu'un avec le même problème à l'avenir.

Comme demandé, voici mon fichier .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
13
luislhl

J'ai eu le même problème avant. Mon problème est que j'ai à la fois python2.x et python3.x sur mon système Ubuntu et je veux que mon projet s'exécute dans un env virtuel dans lequel l'environnement python3 est installé. Comment j'ai résolu ce problème:

apt-get installer python3-pip

pip3 installe uWSGI

C'est tout.

8
kofwang

Si votre environnement virtuel est exécuté sur Python3, vous devez installer uwsgi à l’aide de pip3, et non de pip sinon, le problème d’incompatibilité de version créera ce problème d’importation.

pip uninstall uwsgi    
pip3 install uwsgi
4
Abu Obaida

CELA PEUT ÊTRE MAUVAIS POUR LA SÉCURITÉ POUR PLUSIEURS RAISONS. CELA FONCTIONNE POUR TESTER. MAIS EXAMEN DE SÉCURITÉ AVANT D'UTILISER CETTE SOLUTION EXACTE EN PRODUCTION

Une autre raison pour laquelle cette erreur peut se produire est liée aux autorisations. Si en utilisant un fichier .ini comme décrit dans le didacticiel officiel d'uWSGI pour Django , vous avez peut-être créé le fichier ini avec un utilisateur et un groupe rendant le fichier inaccessible à l'utilisateur qui exécute le processus.

Vérifiez le propriétaire et les autorisations pour le fichier et le chemin du répertoire dans lequel il se trouve. Utilisez chown et chmod pour définir les autorisations nécessaires. 

Sudo chown -R www-data:www-data /srv

Sudo chmod 0775 -R /srv

Dans mon cas, j’utilisais une boîte vagabonde pour les tests et l’utilisateur par défaut est "vagabond" tandis que nginx utilise www-data pour l’utilisateur et le groupe. J'ai défini le propriétaire de tous les fichiers du projet sur l'utilisateur et le groupe www-data et ajouté l'utilisateur vagrant au groupe www-data. 

Sudo gpasswd -a vagrant www-data

Je ne suis pas sûr que ce soit une bonne pratique en matière de sécurité. Je vais donc travailler avec mon administrateur système le moment venu de le mettre en production. Mais pour mon environnement de test, cela fonctionne. Quoi qu'il en soit, les autorisations seront un élément à examiner de près pour bon nombre de ces problèmes.

1
shanemgrey

J'ai eu ce problème lorsque mon homebrew a mis à jour ma version de Python vers Python 3.7 et que cela ne fonctionnait plus. Ce qui a fonctionné pour moi, c’est brew info python - qui vous montrera toutes vos versions Python disponibles. Puis je suis revenu à Python 3.6.5 en utilisant brew switch python 3.6.5.

Après cela, j'ai simplement réinstallé mon uWSGI en utilisant:

pip3 uninstall uwsgi
pip3 install uwsgi

Et cela l'a résolu. Si vous n'êtes pas sûr de la version de Python que vous utilisiez, brew info python vous indique les dates d'installation. De plus, vous pouvez vérifier avec pip3 list si votre uWSGI est installé pour la version actuelle.

J'espère que cela t'aides!

0
Nikita Alexander

J'ai rencontré la même chose et mon problème était avec la version python où uwsgi était en cours d'exécution. uwsgi s’exécutait sur python2, mais mon chemin virtuelenv python était défini sur python3. Cela a créé le conflit, il n'arrêtait pas de localiser le package du site installé.

Double-vérifiez la version de python où uwsgi est en cours d’exécution pour qu’elle soit identique à celle définie sur votre virtualenv.  

0
Faith Nassiwa