This week has been quite productive. I started laying the groundwork for the encrypted lists plugin by making changes from core_changes to different components of both Mailman Core, Mailman-Client and Postorius. I will describe the MRs and ideas behind them here.
Move pipelines to their own package and instantiate dynamically#
This MR makes
Pipelines in Mailman Core work in the same dynamic way as
Chains and other similar Mailman’s components work.
Add plugin infrastructure#
This MR is the biggest one and certainly the most important one for the
pgpmailman plugin and other potential Mailman plugins. It adds a notion of a plugin to Mailman Core. To explain what I mean by a plugin, it’s best to look at its example configuration:
[plugin.example] path: example_plugin class: example_plugin.plugin.ExamplePlugin enable: yes configuration: python:example_plugin.config.example
This configuration defines a plugin called
example (section name). Which resides in the
example_plugin package with the
example_plugin.plugin.ExamplePlugin class implementing the
IPlugin interface, which I will describe in a moment. This plugin is enabled and can use the path
example_plugin.config.example.cfg to load it’s configuration.
Alright now what does this actually do / change / provide in Mailman Core?
- The plugin’s
pathpackage is searched for pluggable components if the plugin is enabled and has a non-empty
pathvalue. A new function similar to
find_componentsis introduced and used,
find_pluggable_components. The components are searched for in subpackages named after what is being searched, common to Mailman Core:
IPipeline(after mailman!287 lands)
- The plugin’s
classis instantiated if the plugin is enabled and has a non-empty
classvalue (and implements the
IPlugininterface has several methods:
pre_hook()-> Is called after instantiation but before Mailman’s db initialization, really just moved the existing
pre_hookconfigurable callable into a plugin infrastructure. Return value unused.
post_hook()-> Is called after
pre_hookand after initialization of Mailman’s db and other dynamic components such as commands, rules, handlers… Return value unused.
rest_object()-> Is called whenever a REST client calls the
/plugins/<plugin.name>/...route, to obtain an object which will respond to REST queries for the plugin rooted at aforementioned route. This method can return
Noneto signify the plugin doesn’t want to expose any REST routes, in which case any calls by clients return 404. Otherwise the object should use the routing system used by Mailman’s REST api (
on_getand so on).
- Mailman also sets the
nameattribute on the plugin object after instantiation, before
pre_hookto the plugin’s name in configuration.
- The plugin can use the path in it’s
configurationoption to load it’s configuration if it needs a config file. The same path resoultion rules apply as for the archivers configuration.
Add description attribute to styles#
Mailing list styles currently have an attribute for name, which for the default styles is:
Which is not particularly human-readable, well it is, but doesn’t look like something to be shown in a web ui such as Postorius. Mapping these style names to their descriptions in Postorius is possible, however since the styles are dynamically found and instantiated, it’s not something practically doable.
So this MR adds a
description attribute to
IStyle and adds the appropriate descriptions to the default styles. Also exposes said description to REST clients.
Add bindings for specifying list style#
This MR adds missing access to the
lists/styles REST api endpoint and another argument
style_name to the Mailman-Client’s
create_list call, which is already recognized in Core and will create a new list with selected style. This will then be used by Postorius.
Add plugin bindings#
This MR depends on mailman!288 as it really just exposes the new REST api added with plugins to Mailman-Client. Since this new api gives plugins control over all the requests to paths after their root, the api in Mailman-Client can not be as high-level and abstracted as it is for lists and other core features. It provides access to plugin’s configuration and a
Plugin.call(path, data, method) similar to
Add list style selection to list creation view#
This MR depends on mailmanclient!28 and mailman!289. It adds another field to the list creation form, prompting the user to select a list style, with the default being pre-selected and list style descriptions being shown.