Предупреждения об отказе от Django 1.9 app_label

Ответ 1

Как указано в предупреждении, это происходит либо:

• Когда вы используете модель, которая не находится в INSTALLED_APPS;
• Или когда вы используете модель до того, как ее приложение будет загружено.

Поскольку вы ссылались на приложение в настройке INSTALLED_APPS, это, скорее всего, вы используете модель до инициализации приложения.

Обычно это происходит, когда у вас есть from .models import SomeModels в раннем сигнале apps.py (например post_migrate). Вместо того, чтобы ссылаться на ваши модели классическим способом, рекомендуется использовать AppConfig.get_model(). Проверьте файл apps.py для импорта любой модели и замените их с помощью этого api.

Например, вместо:

# 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)

Сделайте это:

# 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)

Обратите внимание, что это принудительное применение было введено в ошибке # 21719.

Ответ 2

Аналогичная ошибка. В моем случае ошибка была:

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):

Мое решение было:

Добавлен 'django.contrib.sites' в INSTALLED_APPS

Ответ 3

Я подозреваю, что это будет всего лишь небольшое количество людей, которые видят эту ошибку, для которой это будет вызвано тем же, что и я, но если это поможет кому-то еще, кажется, стоит добавить этот ответ!

Я вдруг увидел много этих ошибок при запуске тестов в какой-то момент - оказалось, что я случайно создал __init__.py на верхнем уровне моего проекта Django, когда он должен был находиться в подкаталоге. Подсказка, что это происходит, это ошибки, которые были такими:

/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):

... включено имя каталога, в котором находится проект (mystupiddjangoproject), в полном имени модели, которое должно быть: alerts.models.Alert.

Чтобы исправить это, мне просто нужно было сделать:

rm __init__.py
rm __init__.pyc

Ответ 4

Я получал подобную ошибку, но вместо того, чтобы жаловаться на модели в своих приложениях, он жаловался на модели в пакетах contrib. Например:

C:\Program Files\Python 2.7\lib\site-packages\django\contrib\sessions\models.py: 27: RemovedInDjango19Warning: класс модели django.contrib.sessions.models.Session не объявляет явную строку app_label и либо не находится в приложении INSTALLED_APPS, либо был импортирован до того, как его приложение было загружено. Это больше не будет поддерживаться в Django 1.9.   class Session (models.Model):

Это вызвано неправильным упорядочением в свойстве INSTALLED_APPS в settings.py. Мой settings.py изначально содержал:

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_* используйте модели из пакетов contrib. Ошибка вызвана использованием моделей перед их объявлением (т.е. Django должен знать о приложениях, содержащих эти модели до).

Чтобы решить эту проблему, необходимо изменить порядок, в котором объявлены приложения. В частности, все приложения Django должны появиться перед пользовательскими приложениями. В моем случае правильный INSTALLED_APPS будет выглядеть так:

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',
)

Теперь я знаю, что это может напрямую не ответить на ваш вопрос, но он отвечает на связанный, и поскольку это единственная ссылка SO, которая отображается в Google при вставке ошибки, я ответил на нее здесь.

Однако, я считаю, что подобная ситуация вызывает вашу проблему:

Убедитесь, что вы заявляете приложения "зависимости" перед приложениями, использующими их!. Ошибки не определяют, какое приложение использует модель, поэтому вам нужно будет нажать приложение, содержащее модель он упоминает верх, один за другим, пока ошибка не исчезнет.

Ответ 5

Добавить метакласс в вашу модель с атрибутом app_label.

class Meta:
    app_label = 'app_model_belongs_to'

Надеюсь, что это сработает!

EDIT: Причина этого заключается в том, что модель существует за пределами стандартных местоположений.

Для получения дополнительной информации обратитесь к: https://docs.djangoproject.com/en/1.8/ref/models/options/#app-label

Ответ 6

Я столкнулся с этой проблемой, и это было связано с тем, как я загружал модуль signal.py из приложения.

Как вы теперь можете сказать, довольно часто возникают проблемы с циркуляцией между сигналами и моделями, и обычно их нужно импортировать из файла приложения __init__.py или из нижней части файла models.py, чтобы избежать их.

Ну, я использовал подход __init__.py, и только перемещение оператора import signals в конец моего файла models.py разрешило проблему.

Надеюсь, это поможет кому-то еще!

Ответ 7

У меня была та же проблема. Я установил точку останова в файле django.db.models.base.py:line82 и попытаюсь выяснить, что вызывает это предупреждение.

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

В принципе, если ваше приложение не существует к этому времени, вы получите это предупреждение. Я понял, что моя проблема в том, что у меня есть сторонняя структура (в моем случае, haystack), которая пытается импортировать одну из моих пользовательских моделей.

Возможно, у вас также есть сторонний пакет, указанный в INSTALLED_APPS, прежде чем ваши пользовательские приложения и ваш сторонний пакет обращаются к вашим пользовательским приложениям? Это было бы возможно, если вы используете что-то вроде рамки Django rest.

Ответ 8

Способ Django 1.9 для этого и предоставление вашему приложению хорошего имени в админе состоит в следующем:

Добавьте файл в ваше приложение с именем apps.py и добавьте в него следующее:

#apps.py
from django.apps import AppConfig


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

Затем в файле приложения __init__.py добавьте следующее:

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

Ответ 9

У меня есть эта проблема после обновления Django с 1,8 до 1,9.1:

RuntimeError при /

Класс модели blog.models.BlogCategory не объявляет явную метку приложения и не находится в приложении в INSTALLED_APPS.

Эта помощь для решения:

в блоге /models.py:

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

    class Meta:
        app_label = 'BlogCategory'

Он работает на 100%.

Ответ 10

Иногда недопустимые .pyc файлы, которые не соответствуют текущему исходному коду, вызвали эту проблему.

Я удалил все .pyc, чтобы обновить все из них, используя этот bash

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

Ответ 11

Самый простой и простой способ решить это - поместить команду "импорт сигналов" в BOTTOM файла модели, с которым вы работаете. Это гарантирует, что все модели будут загружены до того, как будут импортированы сигналы для этой модели. Вам нужно будет сделать это для каждой модели, которую вы импортируете (если вы используете приемники, связанные с конкретными моделями) или в файле models.py для приложения, которое приходит в конце "установленных приложений" в ваших настройках.

Другие решения необходимы только в том случае, если вы имеете дело с сигналами немодельного типа, где модели никогда не будут импортированы в первую очередь.

Почему это не отмечено в документах, это тайна, потому что я просто ее поймал, пока не вспомнил, что вы должны это сделать.

models.py

from django.db import models

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

import signals

И затем в signal.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

Как это.

Ответ 12

Я не получил никаких ошибок в django 1.7. Во время перехода на django 1.8 я получил эту ошибку. Причина заключалась в том, что сигнал был определен в app/signal_receiver.py.

Я создал apps.py

from django.apps import AppConfig

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

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

Я переместил приемник сигнала в handler.py внутри пакета сигналов.