mirror of https://github.com/django/django.git
Changed convention for modules storing AppConfigs.
The app/apps dichotomy was more confusing than valuable.
This commit is contained in:
parent
07711e9997
commit
449ede03b8
|
@ -59,7 +59,7 @@ For application authors
|
|||
If you're creating a pluggable app called "Rock ’n’ roll", here's how you
|
||||
would provide a proper name for the admin::
|
||||
|
||||
# rock_n_roll/app.py
|
||||
# rock_n_roll/apps.py
|
||||
|
||||
from django.apps import AppConfig
|
||||
|
||||
|
@ -67,11 +67,11 @@ would provide a proper name for the admin::
|
|||
name = 'rock_n_roll'
|
||||
verbose_name = "Rock ’n’ roll"
|
||||
|
||||
You would then tell your users to add ``'rock_n_roll.app.RockNRollConfig'`` to
|
||||
their :setting:`INSTALLED_APPS`.
|
||||
You would then tell your users to add ``'rock_n_roll.apps.RockNRollConfig'``
|
||||
to their :setting:`INSTALLED_APPS`.
|
||||
|
||||
The recommended convention is to put the configuration class in a submodule of
|
||||
the application called ``app``. However, this isn't enforced by Django.
|
||||
the application called ``apps``. However, this isn't enforced by Django.
|
||||
|
||||
You must include the :attr:`~django.apps.AppConfig.name` attribute for Django
|
||||
to determine which application this configuration applies to. You can define
|
||||
|
|
Loading…
Reference in New Issue