Django 1.9 deprecation warnings app_label

Question

I've just updated to Django v1.8, and testing my local setup before updating my project and I've had a deprecation warning that I've never seen before, nor does it make any sense to me. I may be just overlooking something or misunderstanding the documentation.

/Users/neilhickman/Sites/guild/ankylosguild/apps/raiding/models.py:6: RemovedInDjango19Warning: Model class ankylosguild.apps.raiding.models.Difficulty doesn't declare an explicit app_label and either isn't in an application in INSTALLED_APPS or else was imported before its application was loaded. This will no longer be supported in Django 1.9.
  class Difficulty(models.Model):

/Users/neilhickman/Sites/guild/ankylosguild/apps/raiding/models.py:21: RemovedInDjango19Warning: Model class ankylosguild.apps.raiding.models.Zone doesn't declare an explicit app_label and either isn't in an application in INSTALLED_APPS or else was imported before its application was loaded. This will no longer be supported in Django 1.9.
  class Zone(models.Model):

/Users/neilhickman/Sites/guild/ankylosguild/apps/raiding/models.py:49: RemovedInDjango19Warning: Model class ankylosguild.apps.raiding.models.Boss doesn't declare an explicit app_label and either isn't in an application in INSTALLED_APPS or else was imported before its application was loaded. This will no longer be supported in Django 1.9.
  class Boss(models.Model):

/Users/neilhickman/Sites/guild/ankylosguild/apps/raiding/models.py:79: RemovedInDjango19Warning: Model class ankylosguild.apps.raiding.models.Item doesn't declare an explicit app_label and either isn't in an application in INSTALLED_APPS or else was imported before its application was loaded. This will no longer be supported in Django 1.9.
  class Item(models.Model):

/Users/neilhickman/Sites/guild/ankylosguild/apps/forum/models.py:14: RemovedInDjango19Warning: Model class ankylosguild.apps.forum.models.Category doesn't declare an explicit app_label and either isn't in an application in INSTALLED_APPS or else was imported before its application was loaded. This will no longer be supported in Django 1.9.
  class Category(models.Model):

/Users/neilhickman/Sites/guild/ankylosguild/apps/forum/models.py:36: RemovedInDjango19Warning: Model class ankylosguild.apps.forum.models.Comment doesn't declare an explicit app_label and either isn't in an application in INSTALLED_APPS or else was imported before its application was loaded. This will no longer be supported in Django 1.9.
  class Comment(ScoreMixin, ProfileMixin, models.Model):

/Users/neilhickman/Sites/guild/ankylosguild/apps/forum/models.py:64: RemovedInDjango19Warning: Model class ankylosguild.apps.forum.models.Forum doesn't declare an explicit app_label and either isn't in an application in INSTALLED_APPS or else was imported before its application was loaded. This will no longer be supported in Django 1.9.
  class Forum(models.Model):

/Users/neilhickman/Sites/guild/ankylosguild/apps/forum/models.py:88: RemovedInDjango19Warning: Model class ankylosguild.apps.forum.models.Post doesn't declare an explicit app_label and either isn't in an application in INSTALLED_APPS or else was imported before its application was loaded. This will no longer be supported in Django 1.9.
  class Post(ScoreMixin, ProfileMixin, models.Model):

/Users/neilhickman/Sites/guild/ankylosguild/apps/forum/models.py:119: RemovedInDjango19Warning: Model class ankylosguild.apps.forum.models.CommentPoint doesn't declare an explicit app_label and either isn't in an application in INSTALLED_APPS or else was imported before its application was loaded. This will no longer be supported in Django 1.9.
  class CommentPoint(models.Model):

/Users/neilhickman/Sites/guild/ankylosguild/apps/forum/models.py:127: RemovedInDjango19Warning: Model class ankylosguild.apps.forum.models.TopicPoint doesn't declare an explicit app_label and either isn't in an application in INSTALLED_APPS or else was imported before its application was loaded. This will no longer be supported in Django 1.9.
  class TopicPoint(models.Model):

/Users/neilhickman/Sites/guild/ankylosguild/apps/auctionhouse/models.py:10: RemovedInDjango19Warning: Model class ankylosguild.apps.auctionhouse.models.Auction doesn't declare an explicit app_label and either isn't in an application in INSTALLED_APPS or else was imported before its application was loaded. This will no longer be supported in Django 1.9.
  class Auction(models.Model):

/Users/neilhickman/Sites/guild/ankylosguild/apps/auctionhouse/models.py:83: RemovedInDjango19Warning: Model class ankylosguild.apps.auctionhouse.models.Bid doesn't declare an explicit app_label and either isn't in an application in INSTALLED_APPS or else was imported before its application was loaded. This will no longer be supported in Django 1.9.
  class Bid(models.Model):

Now this poses 3 questions for me.

1. According to the documentation, Options.app_label isn't a requirement unless the model is outside of the application module, which in my case, it isn't. Secondly, this behaviour was deprecated in 1.7 anyway, so why is it even an issue?
2. The applications are all in the INSTALLED_APPS tuple, so it surely can't be that?
3. Why would the applications not be loaded before they are called if everything is in the INSTALLED_APPS tuple?

If I am indeed doing something wrong, what is the correct way of doing it as the docs don't really clear up what is causing this problem or how to rectify it.

Pinkard

Answer 1

As stated in the warning, this happens either :

• When you're using a model which is not in an INSTALLED_APPS;
• Or when you're using a model before its application is loaded.

Since you did refer the app in the INSTALLED_APPS setting, this is most likely you're using a model before the app initialisation.

Typically, this occurs when you have from .models import SomeModels in an apps.py early signal (for example post_migrate). Instead of referring your models the classic way here, it is recommended to use AppConfig.get_model(). Check your apps.py file for any model import, and replace them using this api.

For example instead of :

# apps.py

from django.apps import AppConfig
from .models import MyModel

def do_stuff(sender, **kwargs):
    MyModel.objects.get() # etc...

class MyAppConfig(AppConfig):
    name = 'src.my_app_label'

    def ready(self):
        post_migrate.connect(do_stuff, sender=self)

Do this :

# apps.py

from django.apps import AppConfig

def do_stuff(sender, **kwargs):
    mymodel = sender.get_model('MyModel')
    mymodel.objects.get() # etc...

class MyAppConfig(AppConfig):
    name = 'src.my_app_label'

    def ready(self):
        post_migrate.connect(do_stuff, sender=self)

Note this enforcement was introduced in bug #21719.

Aguila

Interesting, I don't, however, think this is exactly the issue. I only use signals on one of my apps; would this cause an error for three of my apps? – Pinkard

Well it's up to you to try. I faced this issue and this was how I solved it. Refer to the bug info and the actual code commits to get more info. – Aguila

Thanks. For me my main urls.py was importing a custom model. – Hum

Answer 2

Similar error. In my case the error was:

RemovedInDjango19Warning: Model class django.contrib.sites.models.Site doesn't declare an explicit app_label and either isn't in an application in INSTALLED_APPS or else was imported before its application was loaded. This will no longer be supported in Django 1.9.
class Site(models.Model):

My solution was:

Added 'django.contrib.sites' to INSTALLED_APPS

Sirois

Perhaps I was not clear in my answer as my original error was almost identical to the OP therefore I have updated my answer to make it clearer. In my case I have added the 'django.contrib.sites'. Not sure why in your opinion this answer may not be helpful to others. – Sirois

@Anand S Kumar ...just out of curiosity why did you remove your comment about my post being irrelevant to this question? – Sirois

I am using 1.8. Doing this resulted in django.contrib.sites.models.DoesNotExist: Site matching query does not exist. So I am back to living with the warning. – Palsy

I had a similar issue with django-braces and the Permission model of the django.contrib.auth module. I added django.contrib.auth to the INSTALLED_APPS tuple and it worked. Thanks. – Nephoscope

Answer 3

I suspect it'll be only a tiny minority of people who see this error for whom it will be caused by the same thing as me, but in case it helps someone else it seems worth adding this answer!

I suddenly saw lots of these errors when running tests at one point - it turned out that I had accidentally created a __init__.py at the top level of my Django project when it was meant to be in a subdirectory. The clue that this was happening is that the errors, which were like:

/home/mark/mystupiddjangoproject/alerts/models.py:15: RemovedInDjango19Warning: Model class mystupiddjangoproject.alerts.models.Alert doesn't declare an explicit app_label and either isn't in an application in INSTALLED_APPS or else was imported before its application was loaded. This will no longer be supported in Django 1.9.
  class Alert(models.Model):

... included the name of directory the project is in (mystupiddjangoproject) in the fully qualified model name, which should have been: alerts.models.Alert.

To fix this, I just needed to do:

rm __init__.py
rm __init__.pyc

Campestral

I was afraid no one had a solution to my problem, but this fixed it! – Directly

This helped me as well... it affected a weird subset of my models as well which made it ever more unclear. Thanks! – Manny

I think the root cause is described at code.djangoproject.com/ticket/26570 – Pochard

I only got this error when running unit tests, not when running the application normally and this fixed it! Thanks so much! – Kneehole

Answer 4

I was getting a similar error, but rather than complaining about models in my apps, it was complaining about models in contrib packages. For example:

C:\Program Files\Python 2.7\lib\site-packages\django\contrib\sessions\models.py:27: RemovedInDjango19Warning: Model class django.contrib.sessions.models.Session doesn't declare an explicit app_label and either isn't in an application in INSTALLED_APPS or else was imported before its application was loaded. This will no longer be supported in Django 1.9. class Session(models.Model):

This is caused by a bad ordering in the INSTALLED_APPS property in settings.py. My settings.py initially contained:

INSTALLED_APPS = (
    'my_app_1',
    'my_app_2',
    'my_app_3',
    'bootstrap_admin',
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.messages',
    'django.contrib.sessions',
    'django.contrib.sites',
    'django.contrib.staticfiles',
    'social.apps.django_app.default',
    'mathfilters',
    'rest_framework',
)

my_app_* use models from the contrib packages. The error is caused by using models before declaring them (i.e. Django should know about the apps containing those models before using them).

In order to solve this, the order in which the apps are declared needs to be changed. Specifically, all Django apps should come before the user defined apps. In my case, the correct INSTALLED_APPS would look like:

INSTALLED_APPS = (
    'bootstrap_admin',
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.messages',
    'django.contrib.sessions',
    'django.contrib.sites',
    'django.contrib.staticfiles',
    'social.apps.django_app.default',
    'mathfilters',
    'rest_framework',
    'my_app_1',
    'my_app_2',
    'my_app_3',
)

Now I know this might not directly answer your question, but it answers a related one, and since this is the only SO link that shows on Google when pasting the error, I have answered it here.

However, I believe a similar situation is causing your problem:

Make sure you declare the "dependency" apps before the apps using them! The errors don't really specify which app is using a model, so you would have to push the app containing the model it mentions to the top, one by one, until the error disappears.

Tiebout

Answer 5

Add a meta class to your model with an app_label attribute.

class Meta:
    app_label = 'app_model_belongs_to'

Hope this works!

EDIT: The reason for this is usually that the model exists outside of the standard locations.

For more information refer to: https://docs.djangoproject.com/en/1.8/ref/models/options/#app-label

Middleclass

If you read the docs, you will see that in 1.7 app_label is no longer required. So this really doesn't answer the question. – Pinkard

I see it in the doc's that this is not required in 1.7. However this is a sort of PendingDeporcation error for Django 1.9. This solved the issue for me to get rid of the errors. I have been doing testing and research trying to figure out exactly what is happening but like I said a solution is a solution. – Middleclass

A temporary fix is not a solution, it's just covering up the problem to be dealt with at a later stage. – Pinkard

Fair enough. I will keep working on this to find a better answer. Thanks for the feedback – Middleclass

This was of great help, thanks, because EDIT: The reason for this is usually that the model exists outside of the standard locations. was exactly right. In my I was playing around with django models (inheriting from my project's models) that I was creating in a jupyter notebook running out of my project's docker containers. – Maggio

Answer 6

The Django 1.9 way of handling this and giving your app a nice name in the admin is to do the following:

Add a file in your app named apps.py and add the following to it:

#apps.py
from django.apps import AppConfig


class YourAppNameAppConfig(AppConfig):
    name = 'yourappname'
    verbose_name = 'Your App Name Looking Right'

Then, in your app's __init__.py file, add the following:

#__init__.py    
default_app_config = 'youappname.apps.YourAppNameAppConfig'

Berriman

Answer 7

I faced this issue as well and it was related to the way I was loading the signals.py module from an app.

As you may now, it's quite common to have circular import issues between the signals and the models, and it's usual to import them from the app's __init__.py file or from the bottom of the models.py file to avoid them.

Well, I was using the __init__.py approach, and just moving the import signals statement to the bottom of my models.py file solved the issue.

Hope this helps someone else!

Beltane

Answer 8

I has this problem after upgrade Django from 1.8 to 1.9.1:

RuntimeError at /

Model class blog.models.BlogCategory doesn't declare an explicit app_label and isn't in an application in INSTALLED_APPS.

This help to resolve:

in blog/models.py:

class BlogCategory(models.Model):
    some vars & methods

    class Meta:
        app_label = 'BlogCategory'

It's work on 100%.

Monocyte

This doesn't resolve the problem. As the documentation clearly states that the app label isn't required. I'm looking for a solution to this problem not a bandaid – Pinkard

Do not mislead people with your comments. This solution works, many times tested. Class "Meta" need to use, would be that there was no error during the transfer of the database, because it indicates Django how to call a table in the database. – Studio

The comment is not misleading. The answer does not completely answer the original question. At the time of writing, the documentation stated that this solution was not a requirement thus the error being given was contradicting the documentation. – Pinkard

Thanks for this simple solution. (Why would I want a 'signals.py' anyway?!? :) – Sigismondo

Thanks. This worked perfectly for me. I am following the excellent effectivedjango.com/tutorial/ which (apparently) is not up to snuff with my version of django == 1.9.5. VERY SIMPLE. KEEP UP THE GOOD WORK. DON'T let the critics grind you down. – Mediocre

@РоманАрсеньев: I don't know what all the fuss is about. Your solution worked for me, as it has for others. That doesn't mean it should work for everyone in order for you to post here. Thank you, and like others have said, don't let the critics - especially when they are wrong - get you down. – Footplate

Answer 9

I had the same problem. I put a breakpoint in django.db.models.base.py:line82 and try to figure out what is causing this warning message.

# Look for an application configuration to attach the model to.
app_config = apps.get_containing_app_config(module)

Basically, if your app does not exist by this time, you get that warning. I realized that my problem was that I have a third party framework (in my case, haystack) that tries to import one of my custom models.

Maybe you also have a third party package listed in INSTALLED_APPS before your custom apps and your third party package references your custom apps? This would be possible if you are using something like Django rest framework as well.

Resurrection

Answer 10

Sometimes an invalid .pyc files that doesnt match with the current source code caused this problem.

I removed all .pyc to refresh all of them using this bash

find . -name "*.pyc" -exec rm -rf {} \;

Pompadour

Answer 11

The easiest and simplest way to solve this is to place the "import signals" command at the BOTTOM of the Model file you are working with. This ensures that the models are all loaded before the signals for that model are imported. You would have to do this for each model you are importing (if you use receivers linked to particular models), or in the models.py for the app that comes at the end of the "installed apps" in your settings.

The other solutions are only required if you are dealing with non-model type signals, where the models will never be imported first.

Why this is not noted in the docs is a mystery, because I just got caught by it, until I remembered that you have to do that.

models.py

from django.db import models

class MyModel(models.Model):
    myfield1 = models.CharField()
    myfield2 = models.CharField()

import signals

And then in signals.py:

from django.db.models.signals import pre_save # Or whatever you are using
from django.dispatch import receiver

from .models import MyModel

@receiver(pre_save, sender=MyModel)
def my_receiver(sender, instance, **kwargs):
    mysender = sender
    print mysender

Like that.

Diorio

Answer 12

I didn't receive any error in django 1.7. While migrating to django 1.8 I got this error. Reason was the signal were defined in app/signal_receiver.py.

I created a apps.py

from django.apps import AppConfig

class TasksConfig(AppConfig):
    name = 'core'
    verbose_name = "core"

    def ready(self):
        import core.signal.handler

I moved signal receiver in handler.py inside signal package.

Atrium

Answer 13

I got this error because do with error:

urlpatterns = patterns(
url(r'^my_link/$', views.MyView.as_view(), name='my_view'),...

Do right:

urlpatterns = patterns(
'', # Add this line
url(r'^my_link/$', views.MyView.as_view(), name='my_view'),
...)

Cambrai