Add explicit warning when AppConfig.create() can't choose from multiple subclasses of AppConfig

[schnee]

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 ​documentation, and comparing version code, I determined that the reason was that Django 3.2 added support for ​automatic detection for AppConfig to replace default_app_config, and support for the latter was ​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 ​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.

[Sarah Boyce]

Thank you, this makes sense to me

[schnee]

​https://github.com/django/django/pull/18727

[Sarah Boyce]

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 ​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 ​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