>> 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? > The main problem is that settings are code in Django, and not declarative. You have to *import* them, you don't parse them.
I did that similar to Pretix (mine isn't finished yet): you have to differ between "installed" and "active". Packages which are installed could have a "switch" (which has to be a changeable, cached, database state) where to activate/deactivate it. A deactivated plugin is omitted when itering over its implementations, and doesn't emit signals. That's what you really want, I suppose? I think settings - if they are really just *declarative settings* (without code) - would be nice to be parsed *before* loading apps. But Django uses .py files as settings, which is a blessing and a course. There can be conditionals and code in a settings file, which is cool, but leads to problems. Just to not get me wrong: I don't suggest to change Django settings model here - .py files are ok IMHO. But We have to deal with that somehow. > 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]. Definitely. That's the main reason I had liked to implement a declarative plugin spec file with plugin metadata (and maybe default settings?) instead of having plugin Metadata in the AppConfig as subclass - like Raphael did in Pretix. This is a cool and easy approach, but you *have to* import the plugin for getting the metadata - and plugin code has already run then. It's too late to decide: No I don't want that plugin running. But in the end I decided, that from a security POV, it makes no difference. If you have a plugin already on your server, it doesn't matter if you have a settings.cfg or pluginspec.cfg file to parse. You have to trust the plugin anyway when you run it's main entry point later. And from that POV, using Python code (= a class) as metadata or settings, is ok, so most certainly I will implement Pretix' Metadata system into GDAPS as well, additionally being most compatible with Pretix. >> 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? That was my intention, yes. Because else I would need another entry point system, Django apps are fine except to the fact that they are not pluggable. That's the perfect combination IMHO: Use Django apps as "reusable" apps like DRF etc, like a Mixin which fulfills the same purpose in different contexts, applications etc., and use Django apps that are enhanced as GDAPS plugins to extend *one* single Django application with plugins that could be written by others. That's what Raphael said in his DjangoCon talk. > Sub-plugins opens up the can of works that is dependency resolution. No, this can is already opened when loading plugins/apps via setuptools entry points. I called "Sub-plugins" the ones that live under the same "namespace", if that will be an option. >>> 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. Definitely, but only, if it declares a (at least weak) dependency on that other plugin. PluginA could "support" plugins like PluginB and C *if* they are present, and could then override their defaults. I e.g. decided to implement a "core" plugin - like QtCreator did - to make live easier for versioning - plugins relaying on "CorePlugin>=2.3.5" can't be installed then when CorePlugin is 2.0.0. So Core is like any other plugin. And so all plugins depend on Core plugin and could override its defaults. Next problem here is, what if 2 plugins override the default of a third one. The last in the loading row wins then. There are MANY things to consider - but I decided to just start off, and look where the journey brings me. > But in the end, the projects settings.py should be final. Yes. Christian -- 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 [email protected]. To post to this group, send email to [email protected]. 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/4203175f-50a2-e9b9-0bd7-c50641dc22c0%40nerdocs.at. For more options, visit https://groups.google.com/d/optout.
pEpkey.asc
Description: application/pgp-keys
