I fasten migrations to a completely working application, and it is a subject.

The application in INSTALLED_APPS is :

## projects/foo/foo/main/settings.py from __future__ import unicode_literals # ... INSTALLED_APPS = [ 'django.contrib.admin', 'django.contrib.auth', 'django.contrib.contenttypes', 'django.contrib.sessions', 'django.contrib.messages', 'django.contrib.staticfiles', 'foo.main', ]

DJANGO_SETTINGS_MODULE=foo.main.settings registered.

I even added a print to the settings:

 (env) C:\Users\andreymal\projects\foo>python manage.py makemigrations foo.main [u'django.contrib.admin', u'django.contrib.auth', u'django.contrib.contenttypes' , u'django.contrib.sessions', u'django.contrib.messages', u'django.contrib.stati cfiles', u'foo.main'] App 'foo.main' could not be found. Is it in INSTALLED_APPS?

(tried to change unicode to str - it still does not work)

All the necessary __init__.py also have:

 projects/ - foo/ - foo/ - main/ - static/ - __init__.py - models.py - settings.py - etc. - __init__.py - .gitignore - manage.py - setup.py - etc.

In general, it all works fine, the site starts, static is distributed (and for static, for a minute, you also need the prescribed INSTALLED_APPS - and it is still registered).

So janga still need something?

    1 answer 1

    (as usual, I find the answer immediately after creating the survey)

    Suddenly it turned out that junga has a strangeness :

    Most teams accept a list of “application names.” “Application Name” is the name of the main application package. For example, if the INSTALLED_APPS setting contains the string 'mysite.blog', the application name will be blog.

    Thus, the python manage.py makemigrations main perfectly performs as it should.

    Plus, with the choice of application names, you should be careful, because if foo.main add bar.main to bar.main , then junga will call for a coincidence:

    django.core.exceptions.ImproperlyConfigured: Application labels aren't unique, duplicates: main