Django 1.9 advertencias de desaprobación etiqueta de la aplicación

Error similar. En mi caso el error fue:

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

Mi solución fue:

Añadido 'django.contrib.sites' a INSTALLED_APPS

Sospecho que será solo una pequeña minoría de personas que ven este error para quienes será causado por lo mismo que yo, pero en caso de que ayude a alguien más, ¡parece que vale la pena agregar esta respuesta!

De repente vi muchos de estos errores al ejecutar pruebas en un punto - resultó que accidentalmente había creado un __init__.py en el nivel superior de mi proyecto Django cuando estaba destinado a estar en un subdirectorio. La pista de que esto estaba sucediendo es que los errores, que eran como:

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

... se incluyó el nombre del directorio en el que se encuentra el proyecto (mystupiddjangoproject) en el nombre del modelo completo, que debería haber sido: alerts.models.Alert.

Para arreglar esto, solo necesitaba hacer:

rm __init__.py
rm __init__.pyc

Estaba recibiendo un error similar, pero en lugar de quejarme de los modelos en mis aplicaciones, se quejaba de los modelos en paquetes contrib. Por ejemplo:

C:\Program Files\Python 2.7\lib\site-packages \ django \ contrib \ sessions \ models. py: 27: RemovedInDjango19Warning: Model class django.contrib.sesion.modelo.Session no declara una app_label explícita y, o bien no está en una aplicación en INSTALLED_APPS o bien se importó antes de que se cargara su aplicación. Esto no ya sea compatible con Django 1.9. sesión de clase (modelos.Modelo):

Esto es causado por un mal orden en la propiedad INSTALLED_APPS en settings.py. Mi settings.py inicialmente contenía:

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_* utilice modelos de los paquetes contrib. El error es causado por usar modelos antes de declararlos (es decir, Django debe saber acerca de las aplicaciones que contienen esos modelos antes de usarlos).

Para resolver esto, el orden en el que se declaran las aplicaciones debe cambiarse. Específicamente, todas las aplicaciones de Django deben ir antes que las aplicaciones definidas por el usuario. En mi caso, el INSTALLED_APPS correcto se vería como:

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

Ahora sé que esto podría no responder directamente a su pregunta, pero responde a una relacionada, y ya que este es el único enlace que se muestra en Google al pegar el error, lo he respondido aquí.

Sin embargo, creo que una situación similar está causando su problema:

Asegúrese de declarar las aplicaciones de" dependencia" antes de las aplicaciones que los utilizan! Los errores realmente no especifican qué aplicación está utilizando un modelo, por lo que tendría que empujar la aplicación que contiene el modelo que menciona a la parte superior, uno por uno, hasta que el error desaparezca.

Agregue una meta clase a su modelo con un atributo app_label.

class Meta:
    app_label = 'app_model_belongs_to'

Espero que esto funcione!

EDITAR: La razón de esto es generalmente que el modelo existe fuera de las ubicaciones estándar.

Para obtener más información, consulte: https://docs.djangoproject.com/en/1.8/ref/models/options/#app-label

También me enfrenté a este problema y estaba relacionado con la forma en que estaba cargando el signals.py módulo desde una aplicación.

Como puede que ahora, es bastante común tener problemas de importación circular entre las señales y los modelos, y es habitual importarlos desde el archivo __init__.py de la aplicación o desde la parte inferior del archivo models.py para evitarlos.

Bueno, estaba usando el enfoque __init__.py, y solo moviendo la instrucción import signals al final de mi archivo models.py resolví la issue .

Espero que esto ayude a alguien más!

Yo tenía el mismo problema. Pongo un punto de interrupción en django. db.models.base.py:line82 e intento averiguar qué está causando este mensaje de advertencia.

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

Básicamente, si su aplicación no existe en este momento, recibe esa advertencia. Me di cuenta de que mi problema era que tengo un framework de terceros (en mi caso, haystack) que intenta importar uno de mis modelos personalizados.

Tal vez también tenga un paquete de terceros listado en INSTALLED_APPS antes de sus aplicaciones personalizadas y su tercero ¿el paquete hace referencia a sus aplicaciones personalizadas? Esto sería posible si está utilizando algo como Django rest framework también.

La forma de Django 1.9 de manejar esto y darle a tu aplicación un buen nombre en el administrador es hacer lo siguiente:

Agregue un archivo en su aplicación llamado apps.py y agregue lo siguiente:

#apps.py
from django.apps import AppConfig


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

Luego, en el archivo __init__.py de tu app, agrega lo siguiente:

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

Tengo este problema después de actualizar Django de 1.8 a 1.9.1:

RuntimeError at /

Blog de la clase modelo.modelo.BlogCategory no declara una app_label explícita y no está en una aplicación en INSTALLED_APPS.

Esta ayuda para resolver:

En blog/models.py:

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

    class Meta:
        app_label = 'BlogCategory'

Es trabajo en 100%.

A veces un inválido .los archivos pyc que no coinciden con el código fuente actual causaron este problema.

Eliminé todo .pyc para actualizar todos ellos usando este bash

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

La forma más fácil y sencilla de resolver esto es colocar el comando "importar señales" en la PARTE INFERIOR del archivo de modelo con el que está trabajando. Esto garantiza que todos los modelos se carguen antes de que se importen las señales para ese modelo. Tendría que hacer esto para cada modelo que está importando (si utiliza receptores vinculados a modelos particulares), o en el models.py para la aplicación que viene al final de la" aplicaciones instaladas " en su configuración.

Las otras soluciones solo son necesarias si está tratando con señales de tipo no modelo, donde los modelos nunca se importarán primero.

Por qué esto no se señala en los documentos es un misterio, porque acabo de quedar atrapado por ella, hasta que recordé que tienes que hacer eso.

Models.py

from django.db import models

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

import signals

Y luego en 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

Así.

No recibí ningún error en django 1.7. Al migrar a django 1.8 obtuve este error. La razón fue que la señal se definió en app/signal_receiver.py.

He creado un apps.py

from django.apps import AppConfig

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

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

Moví el receptor de señal en handler.py dentro del paquete de señal.