Hi
Is there a policy reason why
> On 5/16/25 12:09 PM, Thomas Ward via Mailman-Developers wrote:
> > [plugin.example]
> > ```
> > class: example_mm_plugin.hooks.ExamplePlugin
> > enabled: yes
> > config_item_one: Foo
> > config_item_two: Bar
> > config_item_three: 1234567890
> > ```
doesn't work, but instead per Mark Sapiro we must do
> [plugin.example]
> ```
> class: example_mm_plugin.hooks.ExamplePlugin
> enabled: yes
> configuration: /path/to/example.cfg
> ```
> and in /path/to/example.cfg
> ```
> [plugin.example]
> config_item_one: Foo
> config_item_two: Bar
> config_item_three: 1234567890
> ```
> Then in example_archiver.py you would have things like
> ```
> from mailman.config import config
> from mailman.config.config import external_configuration
> ...
> my_config = external_configuration(config.plugin.example.configuration)
> # and then things like
> item_one = my_config.get('plugin.example', 'config_item_one')
> ```
Is there a "that's a bad/dangerous API" reason why we can't have a
scheme where in schema.py we have
[paths.master]
ext_dir: $var_dir/ext
# This path is relative to the top-level of the extension 'example':
ext_schema_file: default.cfg
and $ext_dir/example/default.cfg defines all the configurable
variables in the manner of schema.cfg?
Every plugin's schema would get an implicit 'enabled' variable
defaulting to 'no'. The configuration code could either scan $ext_dir
for importable packages and read their default.cfgs after parsing
schema.cfg, or it could scan and parse [plugin.*] sections in
mailman.cfg for enabled plugins and parse and instantiate their
default.cfg before instatiating the corresponding section.
It really should be possible to create simple extensions with just
example/__init__.py and example/default.cfg, or even just example.py
if the only configuration is to enable it. I repeatedly find myself
hacking core code to implement features (such as a configurable list
style) required by a client that I don't want to add to the
distribution because I think they're a bad idea out of that particular
enterprise context (you know, with particular security or QA
requirements and the internal capability to deal with the issues that
arise), or because like list styles they just should be plugins. But
the current plugin architecture makes it hard and requires a bunch of
fragile futzing around both in writing configurations and in
implementation of configurable plugins.
Note, I don't have an idea of whether this is technically hard to do
(in particular, is there a way to do it without hacking lazr.config?)
I just want to hear opinions about whether it's a bad idea before I
spend time on it.
--
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
