Hello Christian, Regarding your first point, adding "default = True" to 1% of apps in a non-empty file seems better than adding default_app_config = "foo.apps.FooConfig" to 99% of apps in an otherwise empty file (usually). You can see the effect in https://github.com/django/django/pull/12310/commits/91cc52ed55dd1ec6cc05b9aa2d9a48aff3cdf87b.
Best regards, -- Aymeric. > On 13 Jan 2020, at 23:04, Christian González <christian.gonza...@nerdocs.at> > wrote: > > Oh, sorry, I just saw that this is discussed (andanswered) in the PR. > > Am 13.01.20 um 23:03 schrieb Christian González: >> Eh, sorry if I misunderstand - but adding a "default = true" line to an >> AppConfig is the same as addign default_app_config = "foo.apps.FooConfig". >> >> A few things that came to my mind when reading the code: >> >> * You check if there is only one AppConfig available >> (https://github.com/django/django/pull/12310/commits/6a4ee2d02477cac1fa67708ceefda2ffd56bbf96#diff-239ff7e40a4b9921b462471882a575f6R111 >> >> <https://github.com/django/django/pull/12310/commits/6a4ee2d02477cac1fa67708ceefda2ffd56bbf96#diff-239ff7e40a4b9921b462471882a575f6R111>) >> and if so, this one is used - that's perfect IMHO. >> >> * But what if 2 AppConfigs have "default = true" ? Then line #139+ is run, >> and silently the default app config class is used - none of the two ones. >> Maybe an error message would be better. default=true should only be valid >> once! >> >> Best regards, >> >> Christian >> >> >> Am 12.01.20 um 21:42 schrieb Aymeric Augustin: >>> Hello, >>> >>> I created a PR for this: https://github.com/django/django/pull/12310 >>> <https://github.com/django/django/pull/12310> >>> >>> I'd love to get some feedback on the design before I polish the patch. >>> >>> Best regards, >>> >>> -- >>> Aymeric. >>> >>> >>> >>>> On 10 Jan 2020, at 14:18, Christian González >>>> <christian.gonza...@nerdocs.at <mailto:christian.gonza...@nerdocs.at>> >>>> wrote: >>>> >>>> >>>> >>>> Am 08.01.20 um 22:39 schrieb Aymeric Augustin: >>>>> The original intent was to make configuration explicit by having >>>>> settings.py reference directly the target AppConfig class. >>>>> >>>>> - When you write MIDDLEWARE = ["polls"], do you expect Django to enable >>>>> "polls.middleware.PollsMiddleware"? >>>>> - When you write INSTALLED_APPS = ["polls"], do you expect Django to >>>>> enable "polls.apps.PollsAppConfig"? >>>>> >>>>> Many readers of this mailing list will answer "no" and "yes" >>>>> respectively. I think the answer to both should be "no", according to >>>>> Django's design philosophy >>>>> <https://docs.djangoproject.com/en/3.0/misc/design-philosophies/#explicit-is-better-than-implicit>. >>>>> (If you're about to argue that an application can provide more than one >>>>> middleware — I'm aware of this and I know you understood my point anyway.) >>>> Yes, that's exactly what I wanted to state. >>>>> [...] >>>>> >>>>> If we're reversing course, giving up on explicitness and going for magic, >>>>> we could embrace that decision fully: import the "apps" submodule inside >>>>> each application; if it exists and it defines exactly one AppConfig >>>>> subclass, use that as the config for this app. Then app authors can stop >>>>> littering their __init__.py files with default_app_config. >>>> That would be perfect IMHO. One could consider restricting it to the >>>> same-named subclass like the app itself, so the app "foo" would need to >>>> have "FooConfig" as default. >>>> >>>> I'm aware that this violates the 2nd "Zen of Python" principle "Explicit >>>> is better than implicit". and "Special cases aren't special enough to >>>> break the rules." - but the next one says: "Although practicality beats >>>> purity." >>>> >>>> Yes, too much "magic" leads to a system where half of it uses magic, and >>>> the other half not - so it's not predictable for the developer what a >>>> certain line does. >>>> >>>> But exactly in this part I think that having a "sane default" - in the >>>> sense of app loading using by using the app name only - is ok. >>>> >>>> I would bet that the vast majority of apps don't have two AppConfigs. >>>> And to urge all devs to use the more elaborative AppConfig line in >>>> INSTALLED_APPS, just to make such special cases (and THESE are the special >>>> cases!) are possible, is wrong IMHO. >>>> >>>> Let it be easy - even the variable says INSTALLED_APPS, not >>>> INSTALLED_CONFIGS. And let there be the possibility to declare other >>>> AppConfigs on demand. >>>> >>>> Christian >>>> >>>> >>>> >>>> -- >>>> Dr. Christian González >>>> https://nerdocs.at <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 >>>> <mailto:django-developers+unsubscr...@googlegroups.com>. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/django-developers/b37e3655-4253-75a1-b750-6c81a0f6cf26%40nerdocs.at >>>> >>>> <https://groups.google.com/d/msgid/django-developers/b37e3655-4253-75a1-b750-6c81a0f6cf26%40nerdocs.at?utm_medium=email&utm_source=footer>. >>> >>> -- >>> 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 >>> <mailto:django-developers+unsubscr...@googlegroups.com>. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/django-developers/A037EBE4-78A7-4037-9E8A-29DCC604CB85%40polytechnique.org >>> >>> <https://groups.google.com/d/msgid/django-developers/A037EBE4-78A7-4037-9E8A-29DCC604CB85%40polytechnique.org?utm_medium=email&utm_source=footer>. >> -- >> Dr. Christian González >> https://nerdocs.at <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 >> <mailto:django-developers+unsubscr...@googlegroups.com>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-developers/f9dc1734-2148-bef7-95b1-d620f285d989%40nerdocs.at >> >> <https://groups.google.com/d/msgid/django-developers/f9dc1734-2148-bef7-95b1-d620f285d989%40nerdocs.at?utm_medium=email&utm_source=footer>. > -- > Dr. Christian González > https://nerdocs.at <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 > <mailto:django-developers+unsubscr...@googlegroups.com>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/a9df802d-62c8-b0c9-7bf1-820284ad26e3%40nerdocs.at > > <https://groups.google.com/d/msgid/django-developers/a9df802d-62c8-b0c9-7bf1-820284ad26e3%40nerdocs.at?utm_medium=email&utm_source=footer>. > <pEpkey.asc> -- 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/94FE0220-A8BB-4AA7-9079-8F3C0B506B46%40polytechnique.org.
