Django AppConfig Behavior with Inheritance

You've identified an important nuance in Django's application configuration system. According to the Django 5.1 documentation, when Django encounters multiple AppConfig subclasses in an apps.py module, it follows specific rules to determine which one to use.

The Issue

When you import a base AppConfig subclass (like PluginConfig in your example) and then create your own subclass from it, Django sees two AppConfig subclasses in the namespace:

1. The imported PluginConfig
2. Your custom MyPluginConfig

This is why your ready() method isn't being called as expected.

Django's Behavior

According to the documentation:

If the apps.py module contains more than one AppConfig subclass, Django will look for a single one where AppConfig.default is True.

If no AppConfig subclass is found, the base AppConfig class will be used.

Solutions

You have several options to resolve this:

1. Set default = True in your subclass:

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

2. Explicitly specify your config class in INSTALLED_APPS:

   PYTHONCopied
   INSTALLED_APPS = [
       ...,
       "yourapp.apps.MyPluginConfig",
       ...,
   ]

3. Set default = False in the base class (if you control it):

   PYTHONCopied
   class PluginConfig(AppConfig):
       default = False
       # other code...

Best Practice

The most reliable approach is to explicitly set default = True in your subclass. This ensures Django will choose your implementation even when multiple AppConfig subclasses are present.

This behavior is by design rather than a bug. Django needs a way to determine which configuration to use when multiple options exist, and the default attribute provides that mechanism.

For reusable apps or frameworks that provide base AppConfig classes, it would be a good practice to set default = False in those base classes to avoid conflicts with user implementations.