uwsgi + Flask + virtualenv ImportError: no module named site

Question

(Other posts on SO are similar, but none have the specific combination of uwsgi + Flask + virtualenv) (This one is closest)

I installed uwsgi via apt-get. I also tried pip install wsgi. Both gave me the same issue.

Test command:

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

Result:

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

I can otherwise run my app in the virtual env.

Answer 1

The path to your virtual environment is wrong. That's the reason for this error.

I'm using virtualenvwrapper and my virtual environments are set at ~/.virtualenvs. So in my case, the uwsgi call would look something like

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

Hope this helps next time someone comes looking for this one.

Thanks to Cody for pointing it out in the comments.

Answer 2

See the answer from @JRajan first.

If you're sure you just want to suppress the error and not actually solve the underlying issue, you should add --no-site to your command or no-site=true to your uwsgi.ini file.

Answer 3

I had this problem when my homebrew updated my Python version to Python 3.7 and it stopped working. What worked for me was brew info python - that will show you all your available Python versions. Than I rolled back to Python 3.6.5 using brew switch python 3.6.5.

After that I simply reinstalled my uWSGI using:

pip3 uninstall uwsgi
pip3 install uwsgi

And that solved it. If you're not sure what version of Python you were using, brew info python shows you the install dates. Also, you can check using pip3 list if your uWSGI is installed for the current version.

Hope this helps!

Answer 4

If your virtual environment is running on Python3 then you must install uwsgi using pip3, not pip otherwise, version mismatch will create this import problem

pip uninstall uwsgi    
pip3 install uwsgi

Answer 5

I encountered the same and my problem was with the python version where uwsgi was running. uwsgi was running on python2 yet my virtualenv python path was set to python3. This created the conflict, it kept on failing to locate the installed site package.

Double check the python version where uwsgi is running so that it is the same as that set on your virtualenv.

Answer 6

I had the similar issue before. My problem is that I have both python2.x and python3.x on my ubuntu system, and I want my project to run in a virtual env in which python3 environment is installed. How I resolved this issue:

apt-get install python3-pip

pip3 install uWSGI

That's all.

Answer 7

In my case the problem was the python version uWSGI tried to use.

My project was written in python 3.4, but I was not specifying this in uWSGI config. So uWSGI tried to use python 2 and tried to import modules from the folder lib/python2.7 inside the virtualenv.

So I received the 'No module named site' error, because all the modules, including the site module, where inside lib/python3.4, not lib/python2.7.

To solve it, i had to do two things:

• Install the python3 plugin for uWSGI, with:
  apt-get install uwsgi-plugin-python3

• Use it in the .ini config file, with:
  plugins = python34

Hope this helps someone with the same problem in the future.

As requested, here follows my .ini file:

[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

Answer 8

THIS MAY BE BAD FOR SECURITY FOR SEVERAL REASONS. IT WORKS FOR TESTING. BUT REVIEW FOR SECURITY BEFORE USING THIS EXACT SOLUTION IN PRODUCTION

Another reason this error may occur is permissions related. If using an .ini file as described in the official tutorial for uWSGI for django, you may have created the ini file with a user and group that makes the file inaccessible to the user that's running the process.

Check the owner and permissions for the file and the directory path it's in. Use chown and chmod to set the needed permissions.

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

sudo chmod 0775 -R /srv

In my case, I was using a vagrant box for testing and the default user is "vagrant" while nginx is using www-data for the user and group. I have set the owner of all of the files in the project to the www-data user and group and added the vagrant user to the www-data group.

sudo gpasswd -a vagrant www-data

I'm not sure if this is good security practice, so I'll be working with my system admin when the time comes to put it in production. But for my test environment it works. Either way, permissions will be something to look closely at for many of these issues.