mokapot icon indicating copy to clipboard operation
mokapot copied to clipboard

[Pitch] Plugin architecture

Open jspaezp opened this issue 2 years ago • 4 comments

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

jspaezp avatar Oct 17 '22 19:10 jspaezp

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?

wfondrie avatar Oct 21 '22 20:10 wfondrie

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.

jspaezp avatar Oct 22 '22 01:10 jspaezp

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"

wfondrie avatar Oct 24 '22 18:10 wfondrie

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)

jspaezp avatar Oct 24 '22 23:10 jspaezp

Resolved in #75

wfondrie avatar Dec 03 '22 05:12 wfondrie