uwsgi + Flask + virtualenv ImportError：siteという名前のモジュールはありません
（SOの他の投稿は似ていますが、uwsgi + Flask + virtualenv）の特定の組み合わせはありません）（ これは最も近い =）
Apt-getでuwsgiをインストールしました。また、pis install wsgiも試しました。どちらも同じ問題を引き起こしました。
テストコマンド：
Sudo uwsgi -s /tmp/uwsgi.sock -w myapp:app -H myvirtualenv
結果：
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
それ以外の場合は、仮想環境でアプリを実行できます。
最初に@JRajanからの回答を参照してください。
あなたが本当にsuppressしたいだけで、実際にはsolve根本的な問題。コマンドに--no-siteを追加するか、uwsgi.iniファイルにno-site=trueを追加する必要があります。
仮想環境へのパスが間違っています。それがこのエラーの理由です。
私はvirtualenvwrapperを使用しており、仮想環境は〜/ .virtualenvsに設定されています。したがって、私の場合、uwsgi呼び出しは次のようになります。
Sudo uwsgi -s /tmp/uwsgi.sock -w myapp:app -H ~/.virtualenvs/myapp
これが次回誰かがこれを探しに来たときに役立つことを願っています。
コメントで指摘してくれたCodyに感謝します。
私の場合、問題はpython uWSGIが使用しようとしたバージョンです。
私のプロジェクトはpython 3.4で記述されていましたが、uWSGI構成でこれを指定していませんでした。したがって、uWSGIはpython 2を使用して、 virtualenv内のlib/python2.7フォルダー。
そのため、サイトモジュールを含むすべてのモジュールがlib/python2.7ではなくlib/python3.4内にあるため、「サイトという名前のモジュールはありません」というエラーを受け取りました。
それを解決するために、私は2つのことをしなければなりませんでした：
以下を使用して、uWSGI用のpython3プラグインをインストールします。
apt-get install uwsgi-plugin-python3.ini構成ファイルで次のように使用します。
plugins = python34
これが将来同じ問題を持つ誰かを助けることを願っています。
要求に応じて、ここに私の.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
以前にも同様の問題がありました。私の問題は、ubuntuシステムにpython2.xとpython3.xの両方があり、python3環境がインストールされている仮想環境でプロジェクトを実行することです。この問題を解決した方法：
apt-get install python3-pip
pip3インストールuWSGI
それで全部です。
仮想環境がPython3で実行されている場合は、pipではなくpip3を使用してuwsgiをインストールする必要があります。そうでない場合、バージョンの不一致によりこのインポートの問題が発生します。
pip uninstall uwsgi
pip3 install uwsgi
これは、いくつかの理由でセキュリティのために悪いかもしれません。それはテストのために働きます。ただし、この正確なソリューションを本番環境で使用する前にセキュリティを確認してください
このエラーが発生するもう1つの理由は、権限に関連しています。 WSGI for Djangoの公式チュートリアルで説明されている.iniファイルを使用 の場合、プロセスを実行しているユーザーがファイルにアクセスできないようにするユーザーとグループでiniファイルを作成した可能性があります。
ファイルの所有者と権限、およびファイルが含まれているディレクトリパスを確認します。必要な権限を設定するには、chownとchmodを使用します。
Sudo chown -R www-data:www-data /srv
Sudo chmod 0775 -R /srv
私の場合、テストには迷惑なボックスを使用しており、nginxがユーザーとグループにwww-dataを使用している間、デフォルトのユーザーは「vagrant」です。プロジェクト内のすべてのファイルの所有者をwww-dataユーザーとグループに設定し、vagrantユーザーをwww-dataグループに追加しました。
Sudo gpasswd -a vagrant www-data
これが優れたセキュリティ対策であるかどうかはわかりません。したがって、運用環境に入るときは、システム管理者と協力して作業します。しかし、私のテスト環境では動作します。どちらの場合も、権限はこれらの問題の多くを注意深く調べるためのものです。
私の自作が私のPythonバージョンをPython 3.7に更新し、それが機能しなくなったときに、この問題が発生しました。私にとって有効だったのはbrew info pythonでした。利用可能Pythonバージョン。Python 3.6.5をbrew switch python 3.6.5を使用してロールバックした。
その後、私は単にuWSGIを再インストールしました。
pip3 uninstall uwsgi
pip3 install uwsgi
そしてそれで解決しました。使用しているPythonのバージョンがわからない場合は、brew info pythonにインストール日付が表示されます。また、uWSGIが現在のバージョンにインストールされているかどうかをpip3 listを使用して確認できます。
お役に立てれば！
私は同じことに遭遇し、私の問題はpythonでした。uwsgiはpython2で実行されていましたが、virtualenv pythonパスがpython3に設定されていました。これにより競合が発生し、インストールされたサイトパッケージの検索に失敗し続けました。
python uwsgiが実行されているバージョンを確認して、virtualenvで設定されているバージョンと同じであることを確認してください。