Abhilash Raj writes: > Currently, plugins are just python packages and don't require to be > put in a specific directory. The design goal was that it makes > installing plugin easier with `pip` instead of having to copy the > code into a specific directory.
That's fine, Set ext_dir to a sentinel value of some kind, and have that be interpreted as sys.site_packages. As long as there's a way for the configuration code to determine which packages are plugins (eg, existence of a [plugin.PKGNAME] section with enabled==True) which need their schema read, it doesn't matter where they are. I was just riffing on the existence of the ext_dir variable. They can still be distributed as wheels if ext_dir is set. You just need to use "pip install -t $ext_dir ...". > Moreover, maybe I don't remember this correctly, but I don't think > we currently provide a way to define config "schema" for plugins > like we do for Core. `external_configuration` simply provides a way > to read .cfg files parsed by `configparser.ConfigParser` from > stdlib. We don't. I'm suggesting we create one (but only if there's a way to do it without vendoring lazr.config). > I _think_ it might okay to pre-load any provided configuration and > it should be as simple as adding: > > ``` > if string(plugin_config['configuration']) != '': > # pre-load the configuration. > plugin.config = > external_configuration(config.plugin.example.configuration) > ``` Thanks for the hint! > You probably only just need a pyproject.toml and example.py to > implement hooks and REST API endpoints. However, for "components", > it follows a standard dynamic loading mechanism where plugin system > expects that same folder structure as mailman core itself is > followed. In order to define syles or rules, you need to have > package with `example/styles` for Core to be able to discover them. OK, that's exactly the technical detail I was looking for. I don't have a problem with that (even though I chose styles as the example of a one-file plugin I'd like to write). Probably just me but I missed that detail in the documentation. > I am fine if you want to make this simpler and not force Core's > internal directory structure. I'll think about that, but there's a good chance it's a better idea to document the conventions for loading components and provide working examples. > It is a convention we should probably follow in any 1st party > plugins we provide (of which there are currently none) but doesn't > necessarily need to enforced for 3rd party. I was wondering if MTAs might be a candidate for plugin-ization, given that Postfix, Exim4, Sendmail, and qmail have wildly differing APIs for providing routing information. > We could provide a decorator or something like > `@mailman.plugins.style` which would be added on any class > implementing `IStyle` interface and it gets added to > config.styles. Same goes for other components. I need to think about that. People who are writing plugins should be aware of what's going on under the hood. (Styles is an exception; I don't think they should be implemented in code in the first place. It should be possible to write a style in TOML or JSON, unless it's possible to actually extend functionality using a style. But how would that work? You'd need to inform the admin UI about that somehow, and that's going beyond what a core plugin should be trying to do.) > We currently use `mailman.utilities.modules.add_components` in all > the places to discover and load them. > > https://gitlab.com/search?search=add_components&nav_source=navbar&project_id=183616&group_id=124427&search_code=true&repository_ref=master > > The decorator really just needs to do required > initializations/checks and add the component to > `config.{component}`, same/similar to `add_components`. > > Hope this helps! Yes, it helps a lot! I'll take a look at it, and let you know if I have further thoughts or questions. Steve -- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan _______________________________________________ Mailman-Developers mailing list -- mailman-developers@python.org To unsubscribe send an email to mailman-developers-le...@python.org https://mail.python.org/mailman3/lists/mailman-developers.python.org/ Mailman FAQ: https://wiki.list.org/x/AgA3 Security Policy: https://wiki.list.org/x/QIA9
