> I've given some thought to this over the years, and what I think we've > somehow missed in settings until now is ... Namespaces!
I can second this from my POV, having "evaluated" a few plugin systems now. > Any plugin or app ought be able to declare its own settings and their > defaults. And ISTM the "obvious" place to do this is in their AppConfig > > Except, that may be too late, since we may want/need the settings > before apps are loaded? > > So the alternative is for a plugin to declare in its entry points a > reference to its settings declaration. This way, all 3rd party > settings can be gathered, vetted, and applied before having to scan > the INSTALLED_APPS list. I want to separate these things: Yes, AppConfig is too late, as the settings.py is already scanned, and INSTALLED_APPS are determined. That's because Django works this way. I don't recommend Django to completely change its way of loading apps. In GDAPS there are 2 ways of adding apps/plugins: 1. simply add it to INSTALLED_APPS. A GDAPS plugin ins a normal Django app. 2. via setuptools entry point, like pretix. I therefore added my Pluginmanager hook, also like pretix. It just finds the plugins and adds them to INSTALLED_APPS. But here it is too late. settings.py continues, and *afterwords* all the apps are scanned for their settings. you can't override them again in settings.py after that. What would IMHO clean this problem, would be moving INSTALLED_APPS outside of settings.py (maybe in a declarative way: yml, cfg file etc.). Then Django could scan this list, load apps (or do whatever it needs, scan metadata, check for compatibility, etc.), load their settings, and *afterwords* run the main settings.py to eventually override some of the apps' settings globally. This could even be coded with backwards compatibility, e.g. if installed_apps.cfg is present, use that (and disallow INSTALLED_APPS in settings.py), else fall back to settings.INSTALLED_APPS. It wouldn't be necessary to make a setuptools entry point for app/plugin settings. The entry point I would recommend is a "settings.py" for each app - automatically namespaced or better, with a NAMESPACE = "fooplugin" - which would enable having 2 plugins using the same namespace (think of "sub-plugins" of one bigger plugin). > Now what we'll need is a way to avoid namespace clashes, and a > dev-friendly way to update these settings in settings.py I would definitely *allow* namespace clashes, as explained above. Like in partial classes. A "Textprinter" plugin could have 3rdparty sub-plugins, which could use the same namespace (HTMLProviderPlugin, MarkdownProviderPlugin etc.) -- 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/20bd7071-5149-f5e8-86cb-1497d83fc665%40nerdocs.at. For more options, visit https://groups.google.com/d/optout.
pEpkey.asc
Description: application/pgp-keys
