On 6/17/19 5:47 PM, Christian González wrote:
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.
I'm a little unclear here.
Is it too late because you want to be able to exclude settings from
packages that are installed but you don't want "active" in the project?
That you only want 3rd party "settings contributing" plugins to be
activated when selected?
In which case, doesn't it make more sense to include a plugins.cfg to be
processed _before_ settings.py to decide? And if handled well, I expect
only an exclusion list may be required [but an inclusion list would be
safer].
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).
Ah, I think I see now. You want INSTALLED_APPS to be the definitive
truth of all apps _and_ plugins. So it's not possible to have a plugin
that's not also an app?
Sub-plugins opens up the can of works that is dependency resolution.
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.)
Yes, I did consider this. I think it's valid that a plugin may override
another plugins defaults.
But in the end, the projects settings.py should be final.
--
Curtis
--
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/6e74db34-c879-f2d3-89ac-88df9d03804c%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.
