[Django] #35869: Add explicit warning when AppConfig.create() can't choose from multiple subclasses of AppConfig

13 views
Skip to first unread message

Django

unread,
Oct 27, 2024, 4:43:18 AM10/27/24
to django-...@googlegroups.com
#35869: Add explicit warning when AppConfig.create() can't choose from multiple
subclasses of AppConfig
-------------------------------------+-------------------------------------
Reporter: narasux | Type:
| Cleanup/optimization
Status: new | Component: Core
| (Other)
Version: 5.0 | Severity: Normal
Keywords: AppConfig | Triage Stage:
| Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
When I upgraded my Django project from 3.2 to 4.2, I found that the
`ready` method in my custom AppConfig was never executed.

Example Code:


{{{
# apps/demo/__init__.py

default_app_config = "apps.demo.CustomAppConfig"
}}}


{{{
# apps/demo/apps.py

from django.apps import AppConfig


class PlugableAppConfig(AppConfig):

def ready(self):
# do something...


class CustomAppConfig(PlugableAppConfig):
name = "apps.demo"

def ready(self):
super().ready()
# do something...
}}}

After debugging, reading
[https://docs.djangoproject.com/en/4.2/ref/applications/#configuring-
applications documentation], and comparing version code, I determined that
the reason was that Django 3.2 added support for
[https://github.com/django/django/commit/3f2821af6bc48fa8e7970c1ce27bc54c3172545e
automatic detection for AppConfig] to replace `default_app_config`, and
support for the latter was
[https://github.com/django/django/commit/75d6c4ae6df93c4c4d8621aced3a180afa18a6cb
completely removed in version 4.1].

This is a great new feature, but if there are **multiple subclasses** of
AppConfig in apps.py and none of them specify `default` as `True` (legacy
code), `AppConfig.create()` will default to using the Base AppConfig
[https://github.com/django/django/blob/43287cbb87bc5e99a2fd384082a719d8b4d253c6/django/apps/config.py#L155
without any explicit warning].

This could lead to additional troubleshooting costs for developers.
Therefore, I suggest that when `AppConfig.create()` cannot choose among
multiple subclasses of AppConfig and defaults to using the Base AppConfig,
a warning should be raised to alert developers.
--
Ticket URL: <https://code.djangoproject.com/ticket/35869>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

Django

unread,
Oct 27, 2024, 9:19:06 PM10/27/24
to django-...@googlegroups.com
#35869: Add explicit warning when AppConfig.create() can't choose from multiple
subclasses of AppConfig
-------------------------------------+-------------------------------------
Reporter: schnee | Owner: (none)
Type: | Status: new
Cleanup/optimization |
Component: Core (Other) | Version: 5.0
Severity: Normal | Resolution:
Keywords: AppConfig | Triage Stage:
| Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by schnee):

* cc: schnee (removed)

--
Ticket URL: <https://code.djangoproject.com/ticket/35869#comment:1>

Django

unread,
Oct 28, 2024, 6:24:57 AM10/28/24
to django-...@googlegroups.com
#35869: Add explicit warning when AppConfig.create() can't choose from multiple
subclasses of AppConfig
--------------------------------------+------------------------------------
Reporter: schnee | Owner: (none)
Type: Cleanup/optimization | Status: new
Component: Core (Other) | Version: 5.0
Severity: Normal | Resolution:
Keywords: AppConfig | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
--------------------------------------+------------------------------------
Changes (by Sarah Boyce):

* cc: Aymeric Augustin (added)
* stage: Unreviewed => Accepted

Comment:

Thank you, this makes sense to me
--
Ticket URL: <https://code.djangoproject.com/ticket/35869#comment:2>

Django

unread,
Oct 28, 2024, 6:26:30 AM10/28/24
to django-...@googlegroups.com
#35869: Add explicit warning when AppConfig.create() can't choose from multiple
subclasses of AppConfig
--------------------------------------+------------------------------------
Reporter: schnee | Owner: schnee
Type: Cleanup/optimization | Status: assigned
Component: Core (Other) | Version: 5.0
Severity: Normal | Resolution:
Keywords: AppConfig | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
--------------------------------------+------------------------------------
Changes (by Sarah Boyce):

* owner: (none) => schnee
* status: new => assigned

--
Ticket URL: <https://code.djangoproject.com/ticket/35869#comment:3>

Django

unread,
Oct 28, 2024, 7:19:42 AM10/28/24
to django-...@googlegroups.com
#35869: Add explicit warning when AppConfig.create() can't choose from multiple
subclasses of AppConfig
--------------------------------------+------------------------------------
Reporter: schnee | Owner: schnee
Type: Cleanup/optimization | Status: assigned
Component: Core (Other) | Version: 5.0
Severity: Normal | Resolution:
Keywords: AppConfig | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
--------------------------------------+------------------------------------
Comment (by schnee):

https://github.com/django/django/pull/18727
--
Ticket URL: <https://code.djangoproject.com/ticket/35869#comment:4>

Django

unread,
Nov 4, 2024, 5:11:11 AM11/4/24
to django-...@googlegroups.com
#35869: Add explicit warning when AppConfig.create() can't choose from multiple
subclasses of AppConfig
--------------------------------------+------------------------------------
Reporter: schnee | Owner: schnee
Type: Cleanup/optimization | Status: closed
Component: Core (Other) | Version: 5.0
Severity: Normal | Resolution: wontfix
Keywords: AppConfig | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
--------------------------------------+------------------------------------
Changes (by Sarah Boyce):

* resolution: => wontfix
* status: assigned => closed

Comment:

In reviewing the patch, I saw that there was a similar deprecation warning
which has been removed as we are out of the depreciation period, see
https://github.com/django/django/commit/e5fce539bcd7d5cf73cf79aa068cb42aab39a726
#diff-
0f8bc657bc27c9f80385c4814c2c2ebc033bda3e03285a7212965309a481cc70R163-R170

As you experienced this updating from 3.2 to 4.2, this
[https://docs.djangoproject.com/en/5.1/howto/upgrade-version/#resolving-
deprecation-warnings warning would have been available], the question is
now whether we should have a permanent warning or whether this was only a
case for upgrading between versions

If you think a warning is still valuable, you need to start a discussion
on the [https://forum.djangoproject.com/c/internals/5 Django forum] and
get community agreement that this is needed.
I will close the ticket for now as wontfix this can be reopened if the
community agrees this is needed
--
Ticket URL: <https://code.djangoproject.com/ticket/35869#comment:5>
Reply all
Reply to author
Forward
0 new messages