AppConfig subclass prevents django from finding it

Using Django Mystery Errors
1

I may have found a problem/bug in Django as I think this is not the intended behaviour.
Since v3.2 (or so), Django doesn’t rely on default_app_config and searches for AppConfigs in yourapp/apps.py. If there is exactly one AppConfig class defined there, it is taken.
See Applications | Django documentation | Django

So far, so good. But if you declare your AppConfig as subclass of another, the import itself pulls another AppConfig into the apps namespace, so there are (hidden) two in there:

from gdaps.api import PluginConfig  # which in fact is just class PluginConfig(AppConfig)

class MyPluginConfig(PluginConfig):
    # default = True
    def ready(self):
        print("foo")

in INSTALLED_APPS, include "yourapp".

As you may suspect, “foo” is never printed, unless you specify “yourapp.apps.MyPluginConfig”, or declare a default = True in MyPluginConfig.

So in the namespace there are PluginConfig and MyPluginConfig.

I would expect Django to load the MyPluginConfig.

What “could” be done is letting AppConfigs check if the default=True is actually declared IN the very class itself, and ignoring base classes, so I could add a default=False into PluginConfig.

Any suggestions? Is this intended behaviour? It costed me a long time to find this bug in my application, as I suposed Django to load it, and Django didn’t ever complain, which IS intended behaviour as it just ignores the “missing” AppConfig and uses django.apps.AppConfig instead.

2

<conjecture>

I don’t know if it’s specifically “intended”, but it seems to make sense to me based upon my understanding of how module namespaces work.

By using:

you now have a class named PluginConfig in this module that is a subclass of AppConfig.

If you import this as:
from gdaps import api
then you’re not adding another AppConfig to this module.

You would then be able to define your class as:
class MyPluginConfig(api.AppConfig)

</conjecture>