Django 1.9 avertissements de dépréciation app_label
Je viens de mettre à jour Django v1.8, et de tester ma configuration locale avant de mettre à jour mon projet et j'ai reçu un avertissement de dépréciation que je n'avais jamais vu auparavant. J'ai peut-être simplement oublié quelque chose ou mal compris la 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):
Maintenant, cela pose 3 questions pour moi.
- Selon le documentation ,
Options.app_label_ n'est pas obligatoire, sauf si le modèle se trouve en dehors du module d'application, ce qui n'est pas le cas dans mon cas. Deuxièmement, ce comportement a de toute façon été déconseillé dans la version 1.7, alors pourquoi est-ce même un problème? - Les applications sont toutes dans le tuple INSTALLED_APPS, donc ça ne peut sûrement pas être ça?
- Pourquoi les applications ne seraient-elles pas chargées avant d'être appelées si tout est dans le tuple INSTALLED_APPS?
Si je fais effectivement quelque chose de mal, quelle est la bonne façon de le faire, étant donné que les documents n'éclaircissent pas vraiment la cause de ce problème ou la manière de le corriger.
Comme indiqué dans l'avertissement, cela se produit soit:
- Lorsque vous utilisez un modèle qui n'est pas dans un
INSTALLED_APPS; - Ou lorsque vous utilisez un modèle avant que son application ne soit chargée.
Puisque vous avez référencé l'application dans le INSTALLED_APPS _ paramètre, il est fort probable que vous utilisiez un modèle avant l’initialisation de l’application.
Cela se produit généralement lorsque vous avez from .models import SomeModels dans un apps.py signal précoce (par exemple post_migrate). Au lieu de faire référence à vos modèles de la manière classique ici, il est recommandé d'utiliser AppConfig.get_model () . Vérifiez votre fichier apps.py pour toute importation de modèle et remplacez-le à l'aide de cette API.
Par exemple au lieu de:
# 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)
Faire ceci:
# 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)
Notez que cette application a été introduite dans le bug # 21719 .
Erreur similaire. Dans mon cas, l'erreur était:
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):
Ma solution était:
Ajoutée 'Django.contrib.sites' à INSTALLED_APPS
J'imagine que ce ne sera qu'une infime minorité de personnes qui verront cette erreur pour laquelle elle sera causée par la même chose que moi, mais au cas où cela aiderait quelqu'un d'autre, il semble utile d'ajouter cette réponse!
J'ai soudainement vu beaucoup de ces erreurs lors de l'exécution de tests à un moment donné - il s'est avéré que j'avais accidentellement créé un __init__.py au plus haut niveau de mon Django projet quand il était censé être dans un sous-répertoire. L’indication que cela se produisait, c’est que les erreurs, telles que:
/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):
... inclus le nom du répertoire dans lequel se trouve le projet (mystupiddjangoproject) dans le nom complet du modèle, qui aurait dû être: alerts.models.Alert.
Pour résoudre ce problème, je devais juste faire:
rm __init__.py
rm __init__.pyc
Je recevais une erreur similaire, mais plutôt que de me plaindre de modèles dans mes applications, il se plaignait de modèles dans les packages contrib. Par exemple:
C:\Program Files\Python 2.7\lib\site-packages\Django\contrib\sessions\models.py: 27: RemovedInDjango19Warning: La classe de modèle Django.contrib.sessions.models.Session ne déclare pas un app_label explicite et isn 't dans une application dans INSTALLED_APPS ou bien a été importé avant le chargement de son application. Cela ne sera plus supporté dans Django 1.9. Session de classe (models.Model)):
Ceci est dû à un mauvais ordre dans le INSTALLED_APPS propriété dans settings.py. Ma settings.py initialement contenu:
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_* utilise les modèles des packages contrib. L’erreur est causée par l’utilisation de modèles avant de les déclarer (c.-à-d. Django devrait connaître les applications contenant ces modèles avant les utiliser).
Afin de résoudre ce problème, l'ordre dans lequel les applications sont déclarées doit être modifié. Plus précisément, toutes les applications Django doivent précéder les applications définies par l'utilisateur). Dans mon cas, le INSTALLED_APPS ressemblerait à ceci:
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',
)
Maintenant, je sais que cela ne répond peut-être pas directement à votre question, mais à une question connexe, et comme il s’agit du seul lien SO qui apparaît sur Google lors du collage de l’erreur, j’ai répondu ici.
Cependant, je crois qu'une situation similaire est à l'origine de votre problème:
Assurez-vous de déclarer les applications "de dépendance" avant que les applications les utilisent! Les erreurs ne spécifient pas vraiment quelle application utilise un modèle. Vous devez donc sélectionner l'application contenant le modèle qu'elle mentionne. le haut, un par un, jusqu'à ce que l'erreur disparaisse.
Ajoutez une méta-classe à votre modèle avec un attribut app_label.
class Meta:
app_label = 'app_model_belongs_to'
J'espère que ça marche!
EDIT: La raison en est que le modèle existe en dehors des emplacements standard.
Pour plus d'informations, consultez: https://docs.djangoproject.com/fr/1.8/ref/models/options/#app-label
J'ai ce problème après la mise à niveau Django de 1.8 à 1.9.1:
RuntimeError at /
La classe de modèle blog.models.BlogCategory ne déclare pas un app_label explicite et ne figure pas dans une application dans INSTALLED_APPS.
Cette aide à résoudre:
dans blog/models.py:
class BlogCategory(models.Model):
some vars & methods
class Meta:
app_label = 'BlogCategory'
C'est du travail à 100%.
J'ai également fait face à ce problème et cela était lié à la façon dont j'avais chargé le module signs.py à partir d'une application.
Comme vous le pouvez maintenant, il est assez courant d'avoir des problèmes d'importation circulaires entre les signaux et les modèles, et il est habituel de les importer à partir de __init__.py fichier ou à partir du bas de la models.py fichier pour les éviter.
Eh bien, j'utilisais le __init__.py approche, et juste déplaçant le import signals déclaration au bas de mon models.py fichier a résolu le problème.
J'espère que ceci aide quelqu'un d'autre!
La manière Django 1.9 de gérer cela et de donner un nom sympa à votre application dans l’administrateur consiste à effectuer les opérations suivantes:
Ajoutez un fichier dans votre application nommé apps.py Et ajoutez-y les éléments suivants:
#apps.py
from Django.apps import AppConfig
class YourAppNameAppConfig(AppConfig):
name = 'yourappname'
verbose_name = 'Your App Name Looking Right'
Ensuite, dans le fichier __init__.py De votre application, ajoutez ce qui suit:
#__init__.py
default_app_config = 'youappname.apps.YourAppNameAppConfig'
J'ai eu le même problème. Je mets un point d'arrêt dans Django.db.models.base.py:line82 et essaie de comprendre la cause de ce message d'avertissement.
# Look for an application configuration to attach the model to.
app_config = apps.get_containing_app_config(module)
Fondamentalement, si votre application n’existe pas à ce moment-là, vous recevez cet avertissement. J'ai réalisé que mon problème était que je disposais d'un framework tiers (dans mon cas, meule de foin) qui tentait d'importer l'un de mes modèles personnalisés.
Peut-être avez-vous également un package tiers répertorié dans INSTALLED_APPS avant que vos applications personnalisées et votre package tiers ne fasse référence à vos applications personnalisées? Cela serait possible si vous utilisez quelque chose comme Django rest framework.
Parfois, des fichiers .pyc non valides qui ne correspondaient pas au code source actuel étaient à l'origine de ce problème.
J'ai supprimé tous les fichiers .pyc pour les actualiser à l'aide de cette bash
find . -name "*.pyc" -exec rm -rf {} \;
Le moyen le plus simple et le plus simple de résoudre ce problème consiste à placer la commande "importer les signaux" au BAS du fichier de modèle avec lequel vous travaillez. Cela garantit que les modèles sont tous chargés avant que les signaux de ce modèle ne soient importés. Vous devrez le faire pour chaque modèle que vous importez (si vous utilisez des destinataires liés à des modèles particuliers) ou dans le fichier models.py pour l'application située à la fin des "applications installées" dans vos paramètres.
Les autres solutions ne sont nécessaires que si vous traitez avec des signaux de type non-modèle, les modèles ne seront jamais importés en premier.
La raison pour laquelle cela n’est pas mentionné dans les documents est un mystère, car je viens de me faire prendre, jusqu’à ce que je me souvienne que vous devez le faire.
models.py
from Django.db import models
class MyModel(models.Model):
myfield1 = models.CharField()
myfield2 = models.CharField()
import signals
Et puis dans signs.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
Comme ça.
Je n’ai reçu aucune erreur dans Django 1.7. Lors de la migration vers Django 1,8, j’ai eu cette erreur. La raison était que les signaux étaient définis dans app/signal_receiver.py.
J'ai créé un apps.py
from Django.apps import AppConfig
class TasksConfig(AppConfig):
name = 'core'
verbose_name = "core"
def ready(self):
import core.signal.handler
J'ai déplacé le récepteur de signal dans handler.py à l'intérieur du paquet de signaux.