Provide a mechanism for apps to define a default AppConfig

[Russell Keith-Magee]

The AppLoading refactor provides a mechanism for defining an AppConfig object. This AppConfig object provides hooks where you can define useful properties about the app itself. In particular, the ready() method is potentially useful for handling admin autodiscovery, signal registrations, and system checks.

However, it's an opt-in mechanism. You need to explicitly name the appConfig object in your INSTALLED_APPS for the AppConfig object to be used (e.g., django.contrib.auth.apps.AppConfig).he old approach of putting the top level module (e.g., django.contrib.auth) still works.

However, if you use the old approach, none of the AppConfig startup mechanisms are activated, which limits how much functionality we (at a framework level) can put into AppConfig.ready() methods for contrib apps.

There should be a way for apps to specify a "default" AppConfig object, so that if the old-style INSTALLED_APPS declaration is used, that AppConfig object is instantiated.

[Russell Keith-Magee]

Accepting based on ​this discussion on django-dev.

The accepted solution appears to be to put a default_app_config string in django.contrib.auth.__init__.py, and inspect for this string when the AppConfig is instantiated. If the string doesn't exist, we can fall back to using a system default AppConfig object; if it *is* provided, we can instantiate the named object; and if the user points at a specific AppConfig, that class is used.

[Marc Tamlyn]

PR: ​https://github.com/django/django/pull/2192

[Aymeric Augustin]

Marc, thanks for the patch! I'll review it now.

[Aymeric Augustin]

Updated PR: ​https://github.com/django/django/pull/2210

[Aymeric Augustin <aymeric.augustin@…>]

In 2ff93e027c7b35378cc450a926bc2e4a446cacf0:

Fixed #21829 -- Added default AppConfigs.

Thanks Russell for the report, Marc for the initial patch, Carl for the
final review, and everyone who contributed to the design discussion.