Hi Django devs,

A time ago I asked to drop the default_app_config in apps.py or let Django create proper files itself/change all docs to reflect that.

You decided to let Django  search for a AppConfig subclass and load it automatically, if only one is available, or take the one with default=True.

That's fine so far.

I just had a hard time debugging my app with Django4, as in a routine I check for a "PluginMeta" attr in all of my apps, and treat them differently.

I decided to make all my AppConfigs inherit from a special parent AppConfig ("MeduxPluginAppConfig") that provides a few functions like initialize, and others - like pretix does it with its plugin system.

It did not work - no "special" methods and attrs of my plugins where found. I then saw that Django ignored my subclasses of MeduxPluginAppConfig, and just took "AppConfig" instead, like the docs say. But according to the docs, Django should not do that, if there is only one subclass of AppConfig available in apps.py.

I then started debugging Django, and saw that in django.apps.config.py there is the search for the configs:

app_configs = [
    (name, candidate)
    for name, candidatein inspect.getmembers(mod, inspect.isclass)
    if (
        issubclass(candidate,cls)and candidateis not cls and 
getattr(candidate,'default',True)
    )
]

especially `inspect.getmembers` here returns a few "candidates", namely all classes that are found in that apps.py **including imported classes**.

As I have a

from .api import MeduxPluginAppConfig class CommonConfig(MeduxPluginAppConfig):
    ...

, Django thinks that MeduxPluginAppConfig is also a candidate (because it also inherits from AppConfig). Now, there are "2" candidates in this file (for Django), and noone has a default attr. So it ignores them and takes the legacy AppConfig instead.

IMHO this is clearly a bug, unless you tell me that this is intended behaviour, and I should only DIRECTLY inherit AppConfig, and make no further children classes from that one.

Disclaimer: Yes, I know that I am somehow polluting the AppConfig namespace with attrs and methods that could clash with the ones you will add in far future... Pretix does that too, and honestly, there is hardly a good method, except creating  that methods in another model and using AppConfigs only as proxy with a pointer to that model...

I kindly ask for your opinion here.

Christian


--
Dr. Christian González
https://nerdocs.at

--
You received this message because you are subscribed to the Google Groups "Django 
developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a96ae031-c03a-5951-e93c-fc632745311e%40nerdocs.at.

Reply via email to