mokapot
mokapot copied to clipboard
[Pitch] Plugin architecture
Hello there!
I was wondering if you had any interest in adding a plugin architecture to the package? By this a mean allowing someone (me) to implement packages that can modify how mokapot behaves.
The particular use case I can think of is adding a new model to the command line interface. this is my current dummy implementation: https://github.com/jspaezp/mokapot/commit/676bc366dc0fd6cd70ffa9c2b00d1e433fdf9424
if you think its worth it I can add unit testing, documentation and make a PR! Best, Sebastian
Hi @jspaezp - I think this is a great idea. Can you describe more how you imagine it working and maybe a concrete example for how you imagine the interface would work?
Hi there!
So what I was thinking was that ... pip can install entry points to packages, and those can be loaded dynamically. for instance, if a pyproject.toml has this content (I use poetry for package/dependency management ...):
[tool.poetry.plugins."mokapot.plugins"]
"mokapot_ctree" = "mokapot_ctree:PluginModel"
# Equivalent to:
# entry_points={
# 'mkdocs.plugins': [
# 'pluginname = path.to.some_plugin:SomePluginClass',
# ]
# }
It makes the PluginModel
class available by running importlib.metadata.entry_points("mokapot.plugins").load()
So ... if this package (Sample plugin that implements a ctree model):
https://github.com/jspaezp/mokapot/tree/feature/plugin_arch/tests/system_tests/sample_plugin is installed in the same library as mokapot, one could call:
$ mokapot --plugin_model mokapot_ctree data/phospho_rep1.pin
and it runs the ctree model instead of the svc model!
There are many ways to make this more complicated ... such that instead of loading a Model object, it loads a custom class that can also modify the parser. Making it such that the user can have custom arguments for their model. BUT i think its over-kill.
I will make a PR draft just so changes are more evident.
Very cool - I like this idea a lot!
My main request is that we stick with a Setuptools-based build. I think plugins can also be specified in the pyproject.toml:
[project.entry-points."mokapot.plugins"]
"mokapot_ctree" = "mokapot_ctree:PluginModel"
Yeah I'm sure they can be specified using Setuptools as well but for the proof of concept i stuck to what im the most familiar with.
Sounds good! I'll polish it a little bit and make a quick doc explaining how to build plugins and let you know on the PR when I think it's ready to ship (already started writting the testing for it and modified it to make it easier to debug and a little more future proof)
Resolved in #75