In the example <app>Config.ready() calls for a dict update() which will
probably work for a while, before changing the update() call in the example
with more elaborated code.
System checks shoud catch cases where configuration is invalid at all.
Not sure how much you can pull from entry points, if you want to keep
INSTALLED_APPS, but have a hook for your app to autoconfigure itself when
added maybe something like this:
[django.middleware]
DebugToolbarMiddleware = debug_toolbar.middleware.DebugToolbarMiddleware
Otherwise a freeform callbacks should be more flexible to provision common
stuff apps contribute to such as urls, middlewares, template engines ...
It's true that it doesn't look like you're going to be able to meta program
settings really profoundly, ie. different packages wanting different
defaults, but at least seems it can automate most of the work when
installing an app from the ecosystem into a new django project, that could
at least hook sane defaults, for example django-debug-toolbar's AppConfig
could provision middleware and urlconf and then you would only need to add
debug_toolbar to INSTALLED_APPS.
Does INSTALLED_APPS allow to plugin in a given AppConfig with arguments ?
Ie. in cakephp 3.7 that was just released they don't have a list such as
INSTALLED_APPS, but instead you add apps as such:
# that's all they need to setup the debug toolbar in cakephp
Plugin::load('DebugKit')
# but you could load a plugin without having urls injected as such:
Plugin::load('Cors', ['routes' => false]);
Which would be equivalent to something like:
INSTALLED_APPS.load('debug_toolbar')
INSTALLED_APPS.load('otherapp', urls=False)
It looks like app maintainers really ought to give django-gdaps a shot.
Perhaps Christian, another way would be to contribute gdap support to the
apps you like to use in the ecosystem. Then their maintainers could benefit
from it if they install gdaps and so it can propagate in the ecosystem, and
you can consolidate your patterns.
Best
--
∞
--
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CAC6Op1_dMFwwxPwECqc8hk%3DT5HFkcMJjaE3VJ%3Dgo8W_%2B72a5Zg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
