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