django, pyenv, uwsgi - ModuleNotFoundError: No module named 'django'

Question

I have the following vassal configuration in /etc/uwsgi/vassals/gsd.ini:

[uwsgi]
plugins = python
env = DJANGO_SETTINGS_MODULE=%n.settings
virtualenv = /home/toogy/.pyenv/versions/%n
chdir = /home/webapps/%n
module = %n.wsgi:application
master = true
vacuum = true
pidfile = /tmp/uwsgi-%n.pid
socket = /tmp/uwsgi-%n.sock
daemonize = /var/log/uwsgi/%n.log
chmod-socket = 666
uid = toogy
gid = toogy

Here is the uwsgi log I get

Tue Feb  7 10:49:12 2017 - received message 1 from emperor
...gracefully killing workers...
Gracefully killing worker 1 (pid: 31406)...
worker 1 buried after 1 seconds
binary reloading uWSGI...
chdir() to /etc/uwsgi/vassals
closing all non-uwsgi socket fds > 2 (max_fd = 1024)...
found fd 3 mapped to socket 0 (/tmp/uwsgi-gsd.sock)
running /usr/bin/uwsgi
*** has_emperor mode detected (fd: 7) ***
[uWSGI] getting INI configuration from gsd.ini
*** Starting uWSGI 2.0.14 (64bit) on [Tue Feb  7 10:49:13 2017] ***
compiled with version: 6.3.1 20170109 on 18 January 2017 00:35:47
os: Linux-3.14.32-xxxx-grs-ipv6-64 #7 SMP Wed Jan 27 18:05:09 CET 2016
nodename: renard
machine: x86_64
clock source: unix
pcre jit disabled
detected number of CPU cores: 4
current working directory: /etc/uwsgi/vassals
detected binary path: /usr/bin/uwsgi
chdir() to /home/webapps/gsd
your processes number limit is 15700
your memory page size is 4096 bytes
detected max file descriptor number: 1024
lock engine: pthread robust mutexes
thunder lock: disabled (you can enable it with --thunder-lock)
uwsgi socket 0 inherited UNIX address /tmp/uwsgi-gsd.sock fd 3
Python version: 3.6.0 (default, Jan 16 2017, 12:12:55)  [GCC 6.3.1 20170109]
PEP 405 virtualenv detected: /home/toogy/.pyenv/versions/gsd
Set PythonHome to /home/toogy/.pyenv/versions/gsd
*** Python threads support is disabled. You can enable it with --enable-threads ***
Python main interpreter initialized at 0x39d21f0
your server socket listen backlog is limited to 100 connections
your mercy for graceful operations on workers is 60 seconds
mapped 145536 bytes (142 KB) for 1 cores
*** Operational MODE: single process ***
added /home/webapps/gsd/ to pythonpath.
Traceback (most recent call last):
  File "/home/webapps/gsd/gsd/wsgi.py", line 12, in <module>
    from django.core.wsgi import get_wsgi_application
ModuleNotFoundError: No module named 'django'
unable to load app 0 (mountpoint='') (callable not found or import error)
*** no app loaded. going in full dynamic mode ***
*** uWSGI is running in multiple interpreter mode ***
gracefully (RE)spawned uWSGI master process (pid: 27844)
spawned uWSGI worker 1 (pid: 32312, cores: 1)

It cannot find django and I have no idea why because uwsgi seems to detect the python environment (in which django is installed).

Also, it says Python version: 3.6.0 while my virtualenv Python version is 3.5.2. I don't know if this is supposed to happen. The system Python version is 3.6.0.

I am using the last versions of the uwsgi and uwsgi-plugins-python Arch Linux official packages.

Two

Answer 1

The problem was that the system-wide python version linked to uwsgi needs to be the same as the one of the virtualenv, which, I think, is a very stupid thing.

EDIT April 2021: I now recommend using gunicorn, which does not have this problem

Two

You saved my day! This is indeed a stupid requirement. – Lido

@valentin How can I verify if the both are same? If not, how can I fix 'em? – Promiscuity

@SaitejaParsi to know your Python system version: python --version from any terminal, and to know the UWSGI Python version, just run uwsgi and read the logs to know which UWSGI Python version is being used. The way I fixed it at the time was by creating a new env with the Python version used by UWSGI. – Two

I am annoyed to announce that this is still the case. This post needs more upvotes. – Ardeen

I can tell it's still the case with uWSGI==2.0.18 on debian buster... – Miskolc

@Miskolc 2.0.20 on Arch Linux as well. – Possessory

Answer 2

In my case it was using the system wide uwsgi, I'm working using a virtualenv so if I execute

$ which uwsgi

I got /usr/local/python3.6/bin/uwsgi

As Valentin Iovene suggests you need to use the uwsgi from your virtual environment

My directories structure is something like this:

~/Env
--/app
--/bin
----/....
----/uwsgi <-- This should be the good one
----/...
--/include
--/lib

(The app directory is where my django app resides)

In my case uwsgi file hasn't execution permissions so I only executed:

$ chmod +x ~/Env/bin/uwsgi

Finally under my app directory I executed the uwsgi command as follows:

../bin/uwsgi --http :8000 --module app.wsgi

Now I can see my app working now :)

I'm following this guide: https://uwsgi-docs.readthedocs.io/en/latest/tutorials/Django_and_nginx.html

Next steps are configuring nginx and https...

I know it's a late response but hope this helps and shared what worked for me.

Teaser

Answer 3

I also found some possible pitfalls I want to share:

• check, if virtualenv (which is the same as venv, pyhome and home) is set to that directory, that contains the bin, include, lib, ... directories
• check, if the user (uid) can read the files in your project and the libs in virtual environment (this ends in a ModuleNotFoundError instead of a permission error)
• use need-app to exit on failures (this helps for debugging and should be default imho)
• use strict to avoid typos in config (this should also be default...)

• if your test.py runs, try to import modules of your project and your virtual environment, to test if that works. It also helps to add a

  import sys
  print(sys.path)
  

You can also copy the printed sys.path, open a python shell and set sys.path to the same value and try to import the desired wsgi module.

Cribbs

Answer 4

look at this at gsd.ini:

virtualenv = /home/toogy/.pyenv/versions/%n

have you install django under this virtualenv?

Simony

Thank you for your answer. It is indeed installed. – Two

Answer 5

When I execute:

uwsgi --socket client_book.sock --module myproject.wsgi --chmod-socket=666 

in the directory ~/, and I would get the following error:

ModuleNotFoundError: No module named 'myproject.wsgi'

The solution was to run the command one layer deeper in the directory ~/myproject

This way, uwsgi was able to find myproject.wsgi.

This was what fixed it for me.

Pilewort

Welcome to SO! Please format your answer. – Clearstory