Opened 11 years ago
Closed 11 years ago
#21829 closed Cleanup/optimization (fixed)
Provide a mechanism for apps to define a default AppConfig
Reported by: | Russell Keith-Magee | Owned by: | Aymeric Augustin |
---|---|---|---|
Component: | Core (Other) | Version: | dev |
Severity: | Normal | Keywords: | app-loading |
Cc: | app-loading, signals, checks | Triage Stage: | Accepted |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
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.
Change History (6)
comment:1 by , 11 years ago
Cc: | added |
---|---|
Triage Stage: | Unreviewed → Accepted |
comment:2 by , 11 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:4 by , 11 years ago
Keywords: | app-loading added |
---|
Marc, thanks for the patch! I'll review it now.
comment:6 by , 11 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Accepting based on this discussion on django-dev.
The accepted solution appears to be to put a
default_app_config
string indjango.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.