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