Django 2.1

Applications




django

Applications

Django में स्थापित अनुप्रयोगों की एक रजिस्ट्री होती है जो कॉन्फ़िगरेशन को संग्रहीत करती है और आत्मनिरीक्षण प्रदान करती है। यह उपलब्ध models की एक सूची भी रखता है।

इस रजिस्ट्री को केवल apps कहा जाता apps और यह django.apps में उपलब्ध है:

>>> from django.apps import apps
>>> apps.get_app_config('admin').verbose_name
'Admin'

परियोजनाओं और अनुप्रयोगों

शब्द परियोजना एक Django वेब अनुप्रयोग का वर्णन करता है। प्रोजेक्ट पायथन पैकेज को मुख्य रूप से एक सेटिंग मॉड्यूल द्वारा परिभाषित किया गया है, लेकिन इसमें आमतौर पर अन्य चीजें शामिल होती हैं। उदाहरण के लिए, जब आप django-admin startproject mysite चलाते हैं, तो आपको एक mysite प्रोजेक्ट डायरेक्टरी wsgi.py , जिसमें settings.py , urls.py और wsgi.py साथ mysite Python पैकेज wsgi.py । प्रोजेक्ट पैकेज को अक्सर जुड़नार, सीएसएस और टेम्प्लेट जैसी चीजों को शामिल करने के लिए बढ़ाया जाता है, जो किसी विशेष एप्लिकेशन से बंधे नहीं होते हैं।

किसी प्रोजेक्ट की रूट डायरेक्टरी (जिसमें manage.py होता है) आमतौर पर प्रोजेक्ट के सभी एप्लिकेशन के लिए कंटेनर होता है जो अलग से इंस्टॉल नहीं किए जाते हैं।

शब्द आवेदन एक पायथन पैकेज का वर्णन करता है जो कुछ सुविधाओं का सेट प्रदान करता है। आवेदन विभिन्न परियोजनाओं में पुन: उपयोग किए जा सकते हैं

एप्लिकेशन में मॉडल, विचार, टेम्प्लेट, टेम्प्लेट टैग, स्थिर फाइलें, URL, मिडलवेयर, आदि के कुछ संयोजन शामिल हैं। इन्हें आमतौर पर INSTALLED_APPS सेटिंग के साथ प्रोजेक्ट में शामिल INSTALLED_APPS है और वैकल्पिक रूप से अन्य तंत्र जैसे URLconfs, MIDDLEWARE सेटिंग या टेम्पलेट इनहेरिटेंस के साथ शामिल किया जाता है। ।

यह समझना महत्वपूर्ण है कि एक Django एप्लिकेशन कोड का एक सेट है जो फ्रेमवर्क के विभिन्न भागों के साथ इंटरैक्ट करता है। Application ऑब्जेक्ट जैसी कोई चीज़ नहीं है। हालांकि, कुछ स्थान हैं जहां Django को मुख्य रूप से कॉन्फ़िगरेशन के लिए और आत्मनिरीक्षण के लिए स्थापित अनुप्रयोगों के साथ बातचीत करने की आवश्यकता है। यही कारण है कि अनुप्रयोग रजिस्ट्री प्रत्येक स्थापित अनुप्रयोग के लिए AppConfig उदाहरण में मेटाडेटा रखता है।

इस पर कोई प्रतिबंध नहीं है कि एक परियोजना पैकेज को भी एक आवेदन नहीं माना जा सकता है और इसमें मॉडल आदि शामिल हैं (जिसके लिए इसे INSTALLED_APPS जोड़ना होगा)।

अनुप्रयोगों को कॉन्फ़िगर करना

किसी एप्लिकेशन को कॉन्फ़िगर करने के लिए, AppConfig को उप-वर्ग करें और INSTALLED_APPS में उस उप-वर्ग के लिए बिंदीदार पथ डालें।

जब INSTALLED_APPS में एप्लिकेशन मॉड्यूल के लिए बस बिंदीदार पथ होता है, तो Django उस मॉड्यूल में default_app_config चर के लिए जाँच करता है।

यदि यह परिभाषित किया गया है, तो यह उस एप्लिकेशन के लिए AppConfig उपवर्ग के लिए बिंदीदार पथ है।

यदि कोई default_app_config नहीं है, तो Django बेस AppConfig क्लास का उपयोग करता है।

default_app_config उन अनुप्रयोगों को अनुमति देता है जो Django 1.7 को django.contrib.admin से चुनते हैं, जिसमें AppConfig सुविधाओं को उपयोगकर्ताओं को उनके INSTALLED_APPS को अपडेट करने की आवश्यकता के बिना ऑप्ट-इन करना है।

नए अनुप्रयोगों को default_app_config से बचना चाहिए। इसके बजाय उन्हें INSTALLED_APPS में स्पष्ट रूप से कॉन्फ़िगर किए जाने के लिए उपयुक्त AppConfig उपवर्ग के लिए बिंदीदार पथ की आवश्यकता होनी चाहिए।

आवेदन लेखकों के लिए

यदि आप "रॉक 'एन' रोल" नामक एक प्लगेबल ऐप बना रहे हैं, तो यहां बताया गया है कि आप व्यवस्थापक के लिए एक उचित नाम कैसे प्रदान करेंगे:

# rock_n_roll/apps.py

from django.apps import AppConfig

class RockNRollConfig(AppConfig):
    name = 'rock_n_roll'
    verbose_name = "Rock ’n’ roll"

आप इस तरह से अपने एप्लिकेशन लोड को डिफ़ॉल्ट रूप से इस AppConfig उपवर्ग बना सकते हैं:

# rock_n_roll/__init__.py

default_app_config = 'rock_n_roll.apps.RockNRollConfig'

यह कारण होगा जब 'rock_n_roll' उपयोग तब किया जाएगा जब INSTALLED_APPS केवल 'rock_n_roll' । यह आपको अपने उपयोगकर्ताओं को अपनी INSTALLED_APPS सेटिंग को अपडेट करने की आवश्यकता के बिना AppConfig सुविधाओं का उपयोग करने की अनुमति देता है। इस उपयोग के मामले के अलावा, default_app_config का उपयोग करने से बचना सबसे अच्छा है और इसके बजाय INSTALLED_APPS में एप्लिकेशन कॉन्फिग क्लास को निर्दिष्ट करें जैसा कि आगे वर्णित है।

बेशक, आप अपने उपयोगकर्ताओं को उनकी INSTALLED_APPS सेटिंग में 'rock_n_roll.apps.RockNRollConfig' डालने के लिए भी कह सकते हैं। आप विभिन्न व्यवहारों के साथ कई अलग-अलग AppConfig उपवर्ग भी प्रदान कर सकते हैं और अपने उपयोगकर्ताओं को अपनी INSTALLED_APPS सेटिंग के माध्यम से एक चुनने की अनुमति दे सकते हैं।

अनुशंसित सम्मेलन को एप्लिकेशन नामक apps सबमॉड्यूल में कॉन्फ़िगरेशन क्लास डालना है। हालाँकि, यह Django द्वारा लागू नहीं किया गया है।

आपको यह निर्धारित करने के लिए कि यह कॉन्फ़िगरेशन किस एप्लिकेशन पर लागू होता है, यह निर्धारित करने के लिए आपको Django के लिए name विशेषता शामिल करनी होगी। आप AppConfig API संदर्भ में प्रलेखित किसी भी विशेषता को परिभाषित कर सकते हैं।

ध्यान दें

यदि आपका कोड किसी एप्लिकेशन के __init__.py में एप्लिकेशन रजिस्ट्री को आयात करता है, तो नाम apps apps सबमॉडुले से टकराएंगे। सबसे अच्छा अभ्यास उस कोड को एक सबमॉड्यूल में स्थानांतरित करना और इसे आयात करना है। एक भिन्न नाम के तहत रजिस्ट्री को आयात करना है:

from django.apps import apps as django_apps

एप्लिकेशन उपयोगकर्ताओं के लिए

यदि आप anthology नामक एक परियोजना में "रॉक 'एन' रोल" का उपयोग कर रहे हैं, लेकिन आप चाहते हैं कि इसके बजाय "जैज़ मनौचे" के रूप में दिखाया जाए, तो आप अपना स्वयं का कॉन्फ़िगरेशन प्रदान कर सकते हैं:

# anthology/apps.py

from rock_n_roll.apps import RockNRollConfig

class JazzManoucheConfig(RockNRollConfig):
    verbose_name = "Jazz Manouche"

# anthology/settings.py

INSTALLED_APPS = [
    'anthology.apps.JazzManoucheConfig',
    # ...
]

फिर से, apps नामक एक सबमॉड्यूल में प्रोजेक्ट-विशिष्ट कॉन्फ़िगरेशन कक्षाओं को परिभाषित करना एक सम्मेलन है, आवश्यकता नहीं है।

अनुप्रयोग कॉन्फ़िगरेशन

class AppConfig [source]

अनुप्रयोग कॉन्फ़िगरेशन ऑब्जेक्ट किसी अनुप्रयोग के लिए मेटाडेटा संग्रहीत करते हैं। कुछ विशेषताओं को AppConfig उपवर्गों में कॉन्फ़िगर किया जा सकता है। दूसरों को Django और केवल पढ़ने के लिए निर्धारित कर रहे हैं।

विन्यास योग्य विशेषताएँ

AppConfig.name

आवेदन के लिए पूर्ण पायथन मार्ग, जैसे 'django.contrib.admin'

यह विशेषता परिभाषित करती है कि कॉन्फ़िगरेशन किस एप्लिकेशन पर लागू होता है। इसे सभी AppConfig उपवर्गों में सेट किया जाना चाहिए।

यह एक Django परियोजना में अद्वितीय होना चाहिए।

AppConfig.label

आवेदन के लिए संक्षिप्त नाम, जैसे 'admin'

जब दो एप्लिकेशन में परस्पर विरोधी लेबल होते हैं, तो यह विशेषता किसी एप्लिकेशन को रीलेबल करने देती है। यह name के अंतिम घटक को डिफॉल्ट करता है। यह एक मान्य पायथन पहचानकर्ता होना चाहिए।

यह एक Django परियोजना में अद्वितीय होना चाहिए।

AppConfig.verbose_name

आवेदन के लिए मानव-पठनीय नाम, उदाहरण के लिए "प्रशासन"।

यह विशेषता label.title() डिफॉल्ट करती है।

AppConfig.path

एप्लिकेशन निर्देशिका में फ़ाइल सिस्टम पथ, जैसे '/usr/lib/pythonX.Y/dist-packages/django/contrib/admin'

ज्यादातर मामलों में, Django स्वचालित रूप से इसका पता लगा सकता है और इसे सेट कर सकता है, लेकिन आप अपने AppConfig उपवर्ग पर एक वर्ग विशेषता के रूप में एक स्पष्ट ओवरराइड भी प्रदान कर सकते हैं। कुछ स्थितियों में यह आवश्यक है; उदाहरण के लिए यदि ऐप पैकेज कई पथों के साथ एक नाम स्थान पैकेज है।

पढ़ें- केवल विशेषताएँ

AppConfig.module

आवेदन के लिए रूट मॉड्यूल, जैसे <module 'django.contrib.admin' from 'django/contrib/admin/__init__.py'>

AppConfig.models_module

मॉडल युक्त मॉड्यूल, उदाहरण के लिए <module 'django.contrib.admin.models' from 'django/contrib/admin/models.py'>

यदि एप्लिकेशन में models मॉड्यूल None तो यह None हो सकता है। ध्यान दें कि डेटाबेस से संबंधित संकेत जैसे कि pre_migrate और post_migrate केवल उन अनुप्रयोगों के लिए उत्सर्जित होते हैं जिनमें एक models मॉड्यूल होता है।

तरीके

AppConfig.get_models() [source]

इस एप्लिकेशन के लिए Model कक्षाओं का एक पुनरावृत्ति देता है।

एप्लिकेशन रजिस्ट्री को पूरी तरह से आबाद करने की आवश्यकता है।

AppConfig.get_model(model_name, require_ready=True) [source]

दिए गए model_name साथ Model model_namemodel_name केस-असंवेदनशील है।

यदि इस तरह का कोई मॉडल इस एप्लिकेशन में मौजूद नहीं है, तो LookupError

जब तक आवश्यक तर्क पहले से ही False सेट नहीं हो जाता है, तब तक ऐप रजिस्ट्री की पूरी तरह से आबादी की आवश्यकता होती है। require_ready ही apps.get_model() रूप में व्यवहार करता है।

AppConfig.ready() [source]

सबक्लास इस पद्धति को ओवरराइड करने जैसे सिग्नल रजिस्टर करने के लिए आरंभीकरण कार्य कर सकते हैं। रजिस्ट्री पूरी तरह से आबाद होते ही इसे कहा जाता है।

यद्यपि आप मॉड्यूल-स्तर पर मॉडल आयात नहीं कर सकते हैं जहां AppConfig कक्षाएं परिभाषित हैं, आप उन्हें आयात ready() या ready() import विवरण या get_model() का उपयोग करके ready() कर सकते हैं।

यदि आप model signals पंजीकृत कर रहे हैं, तो आप मॉडल वर्ग का उपयोग करने के बजाय इसके स्ट्रिंग लेबल द्वारा प्रेषक को संदर्भित कर सकते हैं।

उदाहरण:

from django.db.models.signals import pre_save

def ready(self):
    # importing model classes
    from .models import MyModel  # or...
    MyModel = self.get_model('MyModel')

    # registering signals with the model's string label
    pre_save.connect(receiver, sender='app_label.MyModel')

चेतावनी

यद्यपि आप ऊपर वर्णित मॉडल कक्षाओं तक पहुंच सकते हैं, अपने ready() कार्यान्वयन में डेटाबेस के साथ बातचीत करने से बचें। इसमें मॉडल विधियाँ शामिल हैं जो क्वेरीज़ को निष्पादित करती हैं ( save() , delete() , मैनेजर के तरीके आदि), और django.db.connection माध्यम से रॉ SQL django.db.connection । आपका ready() तरीका हर मैनेजमेंट कमांड के स्टार्टअप के दौरान चलेगा। उदाहरण के लिए, भले ही परीक्षण डेटाबेस कॉन्फ़िगरेशन उत्पादन सेटिंग्स से अलग है, फिर भी manage.py test आपके उत्पादन डेटाबेस के विरुद्ध कुछ प्रश्नों का निष्पादन करेगा!

ध्यान दें

सामान्य इनिशियलाइज़ेशन प्रक्रिया में, ready विधि को केवल एक बार Django द्वारा बुलाया जाता है। लेकिन कुछ कोने के मामलों में, विशेष रूप से परीक्षणों में जो स्थापित अनुप्रयोगों के साथ फ़िडलिंग हैं, ready को एक से अधिक बार कहा जा सकता है। उस स्थिति में, या तो बेकार तरीके लिखें, या फिर से चलने वाले कोड को रोकने के लिए अपने AppConfig वर्गों पर एक झंडा लगाएं, जिसे ठीक एक बार निष्पादित किया जाना चाहिए।

ऐप के रूप में नामस्पेस पैकेज

बिना __init__.py फाईल के पायथन पैकेज को "नेमस्पेस पैकेज" के रूप में जाना जाता है और sys.path ( PEP 420 देखें) पर विभिन्न स्थानों पर कई निर्देशिकाओं में फैलाया जा सकता है।

Django अनुप्रयोगों के लिए एक एकल आधार फाइल सिस्टम पथ की आवश्यकता होती है जहाँ Django (कॉन्फ़िगरेशन के आधार पर) टेम्पलेट, स्थिर संपत्ति आदि की खोज करेगा। इस प्रकार, नामस्थान पैकेज केवल Django अनुप्रयोग हो सकते हैं यदि निम्न में से कोई एक सत्य है:

  1. नाम स्थान पैकेज में वास्तव में केवल एक ही स्थान होता है (यानी एक से अधिक निर्देशिका में नहीं फैला है।)
  2. एप्लिकेशन को कॉन्फ़िगर करने के लिए उपयोग किए जाने वाले AppConfig वर्ग में एक path श्रेणी विशेषता है, जो कि पूर्ण निर्देशिका पथ है Django आवेदन के लिए एकल आधार पथ के रूप में उपयोग करेगा।

यदि इनमें से कोई भी शर्त पूरी नहीं होती है, तो Django ImproperlyConfigured

आवेदन रजिस्ट्री

apps

एप्लिकेशन रजिस्ट्री निम्नलिखित सार्वजनिक एपीआई प्रदान करती है। जिन विधियों को नीचे सूचीबद्ध नहीं किया गया है वे निजी मानी जाती हैं और बिना सूचना के बदल सकती हैं।

apps.ready

बूलियन विशेषता जो रजिस्ट्री के पूरी तरह से True होने के बाद सेट की गई है और सभी ready() विधियों को कहा जाता है।

apps.get_app_configs()

AppConfig उदाहरणों के एक पुनरावृत्ति देता है।

apps.get_app_config(app_label)

दिए गए app_label साथ आवेदन के लिए एक AppConfig app_label । यदि कोई ऐसी एप्लिकेशन मौजूद नहीं है, तो LookupError

apps.is_installed(app_name)

जाँचता है कि क्या दिए गए नाम वाला कोई आवेदन रजिस्ट्री में मौजूद है या नहीं। app_name ऐप का पूरा नाम है, जैसे 'django.contrib.admin'

apps.get_model(app_label, model_name, require_ready=True)

दिए गए app_label और model_name साथ Model model_name । एक शॉर्टकट के रूप में, यह विधि किसी भी तर्क को app_label.model_name के रूप में स्वीकार करती है। model_name केस-असंवेदनशील है।

यदि कोई ऐसा एप्लिकेशन या मॉडल मौजूद नहीं है, तो LookupError । एक एकल तर्क के साथ बुलाया जाता है जब बिल्कुल एक डॉट नहीं है कि ValueError उठाता है।

जब तक आवश्यक तर्क पहले से ही False सेट नहीं हो जाता है, तब तक ऐप रजिस्ट्री की पूरी तरह से आबादी की आवश्यकता होती है।

सेटिंग की आवश्यकता पहले से ही False से सेट अप मॉडल देखने की अनुमति देता है, जबकि ऐप रजिस्ट्री को आबाद किया जा रहा है , विशेष रूप से दूसरे चरण के दौरान जहां यह मॉडल आयात करता है। तब get_model() मॉडल को आयात करने के समान प्रभाव पड़ता है। मुख्य उपयोग का मामला सेटिंग्स के साथ मॉडल कक्षाओं को कॉन्फ़िगर करना है, जैसे AUTH_USER_MODEL

जब आवश्यकता पहले से ही False , get_model() एक मॉडल वर्ग देता है जो पूरी तरह कार्यात्मक नहीं हो सकता है (उदाहरण के लिए रिवर्स get_model() गायब हो सकते हैं, उदाहरण के लिए) जब तक कि ऐप रजिस्ट्री पूरी तरह से आबाद नहीं हो जाती। इस कारण से, जब भी संभव हो, True के डिफ़ॉल्ट मान के लिए require_ready पहले ही छोड़ देना सबसे अच्छा है।

प्रारंभिक प्रक्रिया

आवेदन कैसे भरे जाते हैं

जब Django शुरू होता है, तो django.setup() एप्लिकेशन रजिस्ट्री को पॉप्युलेट करने के लिए जिम्मेदार होता है।

setup(set_prefix=True) [source]

द्वारा Django विन्यास:

  • सेटिंग्स लोड हो रही हैं।
  • लॉगिंग सेट करना।
  • यदि set_prefix सही है, तो URL रिसॉल्वर स्क्रिप्ट को FORCE_SCRIPT_NAME पर FORCE_SCRIPT_NAME यदि परिभाषित किया गया है, या / अन्यथा।
  • आवेदन रजिस्ट्री को प्रारंभ करना।

इस फ़ंक्शन को स्वचालित रूप से कहा जाता है:

  • Django के WSGI समर्थन के माध्यम से एक HTTP सर्वर चलाते समय।
  • जब एक प्रबंधन आदेश लागू करना।

इसे अन्य मामलों में स्पष्ट रूप से कहा जाना चाहिए, उदाहरण के लिए सादे पायथन लिपियों में।

आवेदन रजिस्ट्री को तीन चरणों में शुरू किया जाता है। प्रत्येक चरण में, Django INSTALLED_APPS के क्रम में सभी अनुप्रयोगों को संसाधित करता है।

  1. पहले Django INSTALLED_APPS में प्रत्येक आइटम आयात करता है।

    यदि यह एक एप्लिकेशन कॉन्फ़िगरेशन क्लास है, तो Django एप्लिकेशन के रूट पैकेज को उसके name विशेषता द्वारा परिभाषित करता है। यदि यह एक पायथन पैकेज है, तो Django एक डिफ़ॉल्ट एप्लिकेशन कॉन्फ़िगरेशन बनाता है।

    इस स्तर पर, आपके कोड को किसी भी मॉडल का आयात नहीं करना चाहिए!

    दूसरे शब्दों में, आपके एप्लिकेशन के रूट पैकेज और आपके एप्लिकेशन कॉन्फ़िगरेशन कक्षाओं को परिभाषित करने वाले मॉड्यूल को किसी भी मॉडल को आयात नहीं करना चाहिए, यहां तक ​​कि अप्रत्यक्ष रूप से भी।

    सख्ती से बोलते हुए, Django मॉडल को आयात करने की अनुमति देता है, जब उनका एप्लिकेशन कॉन्फ़िगरेशन लोड हो जाता है। हालाँकि, INSTALLED_APPS के आदेश पर अनावश्यक बाधाओं से बचने के लिए, इस मंच पर किसी भी मॉडल को आयात नहीं करने की पुरजोर सिफारिश की गई है।

    एक बार जब यह चरण पूरा हो जाता है, तो एपीआई जो अनुप्रयोग कॉन्फ़िगरेशन पर काम करते हैं जैसे कि get_app_config() उपयोग करने योग्य हो जाते हैं।

  2. फिर Django प्रत्येक एप्लिकेशन के models सबमॉड्यूल को आयात करने का प्रयास करता है, अगर कोई है।

    आपको अपने एप्लिकेशन के models/__init__.py या models/__init__.py में सभी मॉडलों को परिभाषित या आयात करना होगा। अन्यथा, इस बिंदु पर एप्लिकेशन रजिस्ट्री पूरी तरह से आबाद नहीं हो सकती है, जिससे ओआरएम की खराबी हो सकती है।

    एक बार जब यह चरण पूरा हो जाता है, तो API जो apps.get_model() जैसे मॉडल पर काम करते हैं, उपयोग योग्य हो जाते हैं।

  3. अंत में Django प्रत्येक एप्लिकेशन कॉन्फ़िगरेशन की ready() विधि चलाता है।

समस्या निवारण

यहाँ कुछ सामान्य समस्याएं हैं जिनका आप आरम्भ में सामना कर सकते हैं:

  • AppRegistryNotReady : यह तब होता है जब कोई एप्लिकेशन कॉन्फ़िगरेशन या कोई मॉडल मॉड्यूल आयात करता है जो कोड को ट्रिगर करता है जो ऐप रजिस्ट्री पर निर्भर करता है।

    उदाहरण के लिए, gettext() एप्लिकेशन रजिस्ट्री का उपयोग अनुप्रयोगों में अनुवाद कैटलॉग को देखने के लिए करता है। आयात समय पर अनुवाद करने के लिए, आपको इसके बजाय gettext_lazy() आवश्यकता होगी। ( gettext() का उपयोग करना gettext() एक बग होगा, क्योंकि अनुवाद सक्रिय भाषा के आधार पर प्रत्येक अनुरोध के बजाय आयात समय पर होगा।)

    मॉडल मॉड्यूल में आयात समय पर ORM के साथ डेटाबेस क्वेरी निष्पादित करना भी इस अपवाद को ट्रिगर करेगा। सभी मॉडल उपलब्ध होने तक ORM ठीक से काम नहीं कर सकता है।

    यह अपवाद तब भी होता है जब आप स्टैंडअलोन पायथन स्क्रिप्ट में django.setup() को कॉल करना भूल जाते हैं।

  • ImportError: cannot import name ... यह तब होता है जब आयात अनुक्रम लूप में समाप्त होता है।

    ऐसी समस्याओं को खत्म करने के लिए, आपको अपने मॉडल मॉड्यूल के बीच निर्भरता को कम करना चाहिए और आयात समय पर यथासंभव कम काम करना चाहिए। आयात समय पर कोड निष्पादित करने से बचने के लिए, आप इसे एक फ़ंक्शन में ले जा सकते हैं और इसके परिणामों को कैश कर सकते हैं। जब आपको पहली बार इसके परिणामों की आवश्यकता होगी तो कोड निष्पादित किया जाएगा। इस अवधारणा को "आलसी मूल्यांकन" के रूप में जाना जाता है।

  • django.contrib.admin स्वचालित रूप से इंस्टॉल किए गए एप्लिकेशन में admin मॉड्यूल के ऑटोडिस्कवरी करता है। इसे रोकने के लिए, अपने 'django.contrib.admin.apps.SimpleAdminConfig' को 'django.contrib.admin.apps.SimpleAdminConfig' बजाय अपने INSTALLED_APPS बदलें।