From 449ede03b84df7edda8fe5410481f4fa24394d4a Mon Sep 17 00:00:00 2001 From: Aymeric Augustin Date: Thu, 2 Jan 2014 23:06:25 +0100 Subject: [PATCH] Changed convention for modules storing AppConfigs. The app/apps dichotomy was more confusing than valuable. --- docs/ref/applications.txt | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/ref/applications.txt b/docs/ref/applications.txt index ed3f33a2cc..0713da76ed 100644 --- a/docs/ref/applications.txt +++ b/docs/ref/applications.txt @@ -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