Allow sysadmins to extend sys.path
Over in !308 (merged) my initial inclination was to add sys.path
extension to the plugin configuration, but @J08nY convinced me that this isn't ideal. However we do need some mechanism to extend sys.path
, otherwise Mailman won't be able to find plugins and other object named by Python path syntax on non-default filesystem locations.
One option would be to just leave sys.path
extension to sysadmins deploying Mailman. They'd just have to arrange for $PYTHONPATH
to be set up correctly however Mailman is invoked in order to find everything they've got installed. IOW, NMY (Not Mailman's Problem) :). That's less than idea though because there could be multiple entry points into Mailman. Think all the runners, CLIs, etc.
So I think it makes sense to provide a mechanism inside Mailman's config files to extend sys.path
consistently. This issue then captures the use cases, requirements, and specs for that feature.
A simple solution would be to add a [mailman]paths
(or to avoid confusion with [paths.*]
sections, perhaps [mailman]syspath
which would be a multiline list of additional file system paths to append to sys.path
, in order. That would mean if you provide a plugin, either as part of a Linux distro or as a third party, you'd have to also tell the sysadmin how to extend [mailman]syspath
. That might be okay as a Linux distro would probably have one directory into which all of its supported plugins would be added. E.g.
/usr/share/mailman/plugins
example1/__init__.py
example1/example.py
example2/__init__.py
example2/plugin.py
...
Then only /usr/share/mailman/plugins
would have to be added.