Je suis à bout. Après une douzaine d'heures de dépannage, probablement plus, je pensais être enfin en affaires, mais ensuite j'ai eu:
Model class Django.contrib.contenttypes.models.ContentType doesn't declare an explicit app_label
Il y a SO LITTLE info sur ce site et aucune solution n'a permis de résoudre mon problème. Tout conseil serait extrêmement apprécié.
J'utilise Python 3.4 et Django 1.10.
De mon settings.py:
INSTALLED_APPS = [
'DeleteNote.apps.DeletenoteConfig',
'LibrarySync.apps.LibrarysyncConfig',
'Django.contrib.admin',
'Django.contrib.auth',
'Django.contrib.contenttypes',
'Django.contrib.sessions',
'Django.contrib.messages',
'Django.contrib.staticfiles',
]
Et mes fichiers apps.py ressemblent à ceci:
from Django.apps import AppConfig
class DeletenoteConfig(AppConfig):
name = 'DeleteNote'
et
from Django.apps import AppConfig
class LibrarysyncConfig(AppConfig):
name = 'LibrarySync'
Manquez-vous de saisir le nom de votre application dans le fichier de paramètres? La myAppNameConfig
est la classe par défaut générée à apps.py par la commande .manage.py createapp monAppName . Où myAppName est le nom de votre application.
settings.py
INSTALLED_APPS = [
'myAppName.apps.myAppNameConfig',
'Django.contrib.admin',
'Django.contrib.auth',
'Django.contrib.contenttypes',
'Django.contrib.sessions',
'Django.contrib.messages',
'Django.contrib.staticfiles',
]
De cette façon, le fichier de paramètres détecte ce que vous voulez appeler votre application. Vous pouvez modifier son apparence ultérieurement dans le fichier apps.py en ajoutant le code suivant dans
myAppName/apps.py
class myAppNameConfig(AppConfig):
name = 'myAppName'
verbose_name = 'A Much Better Name'
J'ai eu exactement la même erreur lors de l'exécution de tests avec PyCharm. Je l'ai corrigé en définissant explicitement la variable d'environnement Django_SETTINGS_MODULE
. Si vous utilisez PyCharm, appuyez simplement sur le bouton Modifier les configurations et choisissez Variables d'environnement .
Définissez la variable sur your_project_name.settings
et cela devrait résoudre le problème.
Il semble que cette erreur se produise car PyCharm exécute des tests avec son propre manage.py
.
J'ai eu celui-ci quand j'ai utilisé ./manage.py Shell
Puis j'ai importé accidentellement à partir du répertoire racine du projet
# don't do this
from project.someapp.someModule import something_using_a_model
# do this
from someapp.someModule import something_using_a_model
something_using_a_model()
J'ai eu le même problème tout à l'heure. J'ai corrigé le mien en ajoutant un espace de nom sur le nom de l'application. J'espère que quelqu'un trouvera cela utile.
apps.py
from Django.apps import AppConfig
class SalesClientConfig(AppConfig):
name = 'portal.sales_client'
verbose_name = 'Sales Client'
Je reçois la même erreur et je ne sais pas comment résoudre ce problème. Il m'a fallu de nombreuses heures pour constater que j'ai un init.py dans le même répertoire que le manage.py de Django.
Avant:
|-- myproject
|-- __init__.py
|-- manage.py
|-- myproject
|-- ...
|-- app1
|-- models.py
|-- app2
|-- models.py
Après:
|-- myproject
|-- manage.py
|-- myproject
|-- ...
|-- app1
|-- models.py
|-- app2
|-- models.py
Il est assez confus que vous obteniez l'erreur "ne déclare pas un app_label explicite". Mais la suppression de ce fichier init résolut mon problème.
en tant que noob utilisant Python3 , je trouve que cela pourrait être une erreur d'importation au lieu d'une erreur Django
faux:
from someModule import someClass
droite:
from .someModule import someClass
cela se produit il y a quelques jours mais je ne peux vraiment pas le reproduire ... Je pense que seules les personnes nouvelles à Django peuvent rencontrer ce problème. Voici ce dont je me souviens:
essayez d'enregistrer un modèle dans admin.py:
from Django.contrib import admin
from user import User
admin.site.register(User)
essayez de faire tourner le serveur, l'erreur ressemble à ceci
some lines...
File "/path/to/admin.py" ,line 6
tell you there is an import error
some lines...
Model class Django.contrib.contenttypes.models.ContentType doesn't declare an explicit app_label
changer user
en .user
, problème résolu
J'ai eu cette erreur en essayant de mettre à niveau mon Django Rest Framework app vers DRF 3.6.3 et Django 1.11.1.
Pour quiconque dans cette situation, j’ai trouvé ma solution dans un numéro de GitHub , qui consistait à désactiver le paramètre UNAUTHENTICATED_USER
dans les paramètres DRF :
# webapp/settings.py
...
REST_FRAMEWORK = {
...
'UNAUTHENTICATED_USER': None
...
}
dans mon cas, j'ai pu trouver un correctif et en regardant le code de tout le monde, le problème était peut-être le même. J'ai simplement dû ajouter 'Django.contrib.sites' à la liste des applications installées dans le fichier settings.py fichier.
espérons que cela aide quelqu'un. c'est ma première contribution à la communauté du codage
Je viens de rencontrer ce problème et de comprendre ce qui n'allait pas. Puisqu'aucune réponse précédente n'a décrit le problème tel qu'il m'est arrivé, je pensais le poster pour les autres:
python migrate.py startapp myApp
à partir du dossier racine de mon projet, puis de déplacer myApp dans un dossier enfant avec mv myApp myFolderWithApps/
.python migrate.py makemigrations
. Tout allait bien.myFolderWithApps.myApp
pour faire référence à mon application, mais j'avais oublié de mettre à jour MyApp/apps.py. J'ai donc corrigé myApp/apps.py, paramètres/INSTALLED_APPS et mon chemin d'importation dans ma deuxième application.Donc, pour faire une histoire courte: - le problème provenait initialement d'un nom d'application incorrect dans apps.py de myApp, dans les paramètres et dans le chemin d'importation de ma deuxième application . - mais il ne suffisait pas de corriger les chemins d'accès dans ces trois emplacements, car les migrations avaient été créées avec des importations faisant référence au mauvais nom d'application. Par conséquent, la même erreur s'est produite lors de la migration (sauf pour les migrations cette fois).
Alors ... vérifiez vos migrations et bonne chance!
Dans mon cas, cela se produisait parce que j’utilisais un chemin de module relatif au niveau du projet rls.py, INSTALLED_APPS
et apps.py
au lieu d’être enraciné dans la racine du projet. c'est-à-dire des chemins de modules absolus, plutôt que des chemins de modules relatifs + hacks.
Peu importe combien j'ai gâché les chemins dans INSTALLED_APPS
et apps.py
dans mon application, je ne pouvais pas obtenir à la fois runserver
et pytest
jusqu'à ce qu'ils soient tous les trois enraciné dans la racine du projet.
Structure du dossier:
|-- manage.py
|-- config
|-- settings.py
|-- urls.py
|-- biz_portal
|-- apps
|-- portal
|-- models.py
|-- urls.py
|-- views.py
|-- apps.py
Avec ce qui suit, je pourrais exécuter manage.py runserver
et gunicorn avec wsgi et utiliser portal
app vues sans problème, mais pytest commettrait une erreur avec ModuleNotFoundError: No module named 'apps'
même si Django_SETTINGS_MODULE
était correctement configuré.
config/settings.py:
INSTALLED_APPS = [
...
"apps.portal.apps.PortalConfig",
]
biz_portal/apps/portal/apps.py:
class PortalConfig(AppConfig):
name = 'apps.portal'
config/urls.py:
urlpatterns = [
path('', include('apps.portal.urls')),
...
]
Changer la référence de l'application dans config/settings.py en biz_portal.apps.portal.apps.PortalConfig
et PortalConfig.name
en biz_portal.apps.portal
autorisait l'exécution de pytest (je n'ai pas encore de tests pour portal
vues) mais runserver
serait une erreur avec
RuntimeError: La classe de modèle apps.portal.models.Business ne déclare pas d'étiquette d'application explicite et ne figure pas dans une application dans INSTALLED_APPS.
Finalement, je suis allé chercher apps.portal
pour voir ce qui utilise encore un chemin relatif, et j'ai trouvé que config/urls.py devrait également utiliser biz_portal.apps.portal.urls
.
Dans mon cas, j'ai eu cette erreur lors du portage du code de Django 1.11.11 vers Django 2.2. Je définissais une classe dérivée FileSystemStorage personnalisée. Dans Django 1.11.11, j'avais la ligne suivante dans models.py:
from Django.core.files.storage import Storage, DefaultStorage
et plus tard dans le fichier, j'ai eu la définition de classe:
class MyFileStorage(FileSystemStorage):
Cependant, dans Django 2.2, je dois explicitement faire référence à la classe FileSystemStorage
lors de l'importation:
from Django.core.files.storage import Storage, DefaultStorage, FileSystemStorage
et voilà !, l'erreur disparaît.
Notez que tout le monde rapporte la dernière partie du message d'erreur généré par le serveur Django. Cependant, si vous faites défiler vers le haut, vous trouverez la raison au milieu de cette erreur mambo-jambo.
J'ai rencontré cette erreur lorsque j'ai essayé de générer des migrations pour une seule application dont les migrations étaient mal formées en raison d'une fusion de git. par exemple.
manage.py makemigrations myapp
Quand j'ai supprimé ses migrations, puis exécuté:
manage.py makemigrations
l'erreur ne s'est pas produite et les migrations ont été générées avec succès.
J'ai aussi cette erreur aujourd'hui. Le message faisait référence à une application spécifique de mes applications dans INSTALLED_APPS . Mais en fait, cela n'avait rien à voir avec cette application spécifique. J'ai utilisé un nouvel environnement virtuel et j'ai oublié d'installer certaines bibliothèques, que j'ai utilisées dans ce projet. Après avoir installé les bibliothèques supplémentaires, cela a fonctionné.
J'ai eu cette erreur dans PyCharm et j'ai réalisé que mon fichier de paramètres n'était pas du tout importé. Il n’ya pas d’erreur évidente qui m’ait dit cela, mais lorsque j’ai mis du code absurde dans le fichier settings.py, cela n’a causé aucune erreur.
J'ai eu settings.py à l'intérieur d'un dossier local_settings . Cependant, il serait préférable d’inclure un __init__.py dans le même dossier pour pouvoir l’importer. L'ajout d'un blanc __init__.py a corrigé le problème pour moi.
Très probablement, vous avez des importations dépendantes .
Dans mon cas, j'ai utilisé une classe de sérialiseur en tant que paramètre dans mon modèle et la classe de sérialiseur utilisait ce modèle: Serializer_class = AccountSerializer
from ..api.serializers import AccountSerializer
class Account(AbstractBaseUser):
serializer_class = AccountSerializer
...
Et dans le fichier "sérialiseurs":
from ..models import Account
class AccountSerializer(serializers.ModelSerializer):
class Meta:
model = Account
fields = (
'id', 'email', 'date_created', 'date_modified',
'firstname', 'lastname', 'password', 'confirm_password')
...
J'ai eu cette erreur lors de l'importation de modèles dans les tests, c'est-à-dire étant donné cette structure de projet Django:
|-- myproject
|-- manage.py
|-- myproject
|-- myapp
|-- models.py # defines model: MyModel
|-- tests
|-- test_models.py
dans le fichier test_models.py
j'ai importé MyModel
de cette façon:
from models import MyModel
Le problème a été corrigé s'il est importé de cette manière:
from myapp.models import MyModel
J'espère que cela t'aides!
PS: Peut-être que c'est un peu tard, mais je n'ai pas trouvé dans d'autres réponses comment résoudre ce problème dans mon code et je veux partager ma solution.
J'ai eu cette erreur aujourd'hui en essayant de lancer Django tests parce que j'utilisais la syntaxe abrégée from .models import *
dans l'un de mes fichiers. Le problème était que j'avais une structure de fichier comme celle-ci:
apps/
myapp/
models/
__init__.py
foo.py
bar.py
et dans models/__init__.py
j'importais mes modèles en utilisant la syntaxe abrégée:
from .foo import *
from .bar import *
Dans mon application, j'importais des modèles comme suit:
from myapp.models import Foo, Bar
Cela provoquait le Django model doesn't declare an explicit app_label
lors de l'exécution de ./manage.py test
.
Pour résoudre le problème, je devais importer explicitement du chemin complet dans models/__init__.py
:
from myapp.models.foo import *
from myapp.models.bar import *
Cela a pris soin de l'erreur.
H/t https://medium.com/@michal.bock/fix-weird-exceptions-when-running-Django-tests-f58def71b59a
J'ai eu cette erreur aujourd'hui et je me suis retrouvé ici après avoir googlé. Aucune des réponses existantes ne semble pertinente pour ma situation. La seule chose à faire était d'importer un modèle à partir de mon fichier __init__.py
au plus haut niveau d'une application. J'ai dû déplacer mes importations dans les fonctions à l'aide du modèle.
Django semble avoir un code étrange qui peut échouer de la sorte dans de nombreux scénarios!
J'ai une erreur similaire lors de la construction d'une API dans Django rest_framework.
RuntimeError: La classe de modèle apps.core.models.University ne déclare pas un> app_label explicite et ne figure pas dans une application dans INSTALLED_APPS.
la réponse de luke_aus m'a aidé en corrigeant mon urls.py
de
from project.apps.views import SurgeryView
à
from apps.views import SurgeryView
J'ai reçu cette erreur après avoir déplacé le SECRET_KEY
à extraire d'une variable d'environnement et j'ai oublié de le définir lors de l'exécution de l'application. Si vous avez quelque chose comme ça dans votre settings.py
SECRET_KEY = os.getenv('SECRET_KEY')
assurez-vous ensuite que vous définissez la variable d'environnement.