id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
31180	Deprecate default_app_config.	Aymeric Augustin	Aymeric Augustin	"Many pluggable applications are configured with a dotted path to the app (e.g. `""django.contrib.admin""`) in `INSTALLED_APPS`.

The application then relies on `default_app_config` for locating its `AppConfig` class (e.g. `""django.contrib.admin.apps.AdminConfig""`).

`default_app_config` was intended to allow author of pluggable applications to take advantage of `AppConfig` features without require their users to change `INSTALLED_APPS`, in order to increase adoption.

Unfortunately, that reduced the incentive for directly putting paths to `AppConfig` in `INSTALLED_APPS`. Even though that was the official recommendation, it didn't gain traction.

If I had better anticipated this result, I wouldn't have introduced `default_app_config` in the app-loading refactor in Django 1.7.

We've spent about five years failing at getting people to adopt explicit configuration. It's time to admit failure. Practicality beats purity.

With the benefit of hindsight, I'm proposing to load `AppConfig` classes from a conventional location, namely the `apps` submodule inside an application.

This is inconsistent with Django's design philosophy, as Django favors configuration over convention, but not much worse than the `default_app_config` convention.

There's a small risk of backwards-incompatibility. Django could import an `apps.py` submodule designed for another purpose and that could have side effects. I think that risk is low."	New feature	closed	Core (Other)	dev	Normal	fixed			Ready for checkin	1	0	0	0	0	0