Support for plugins

[geier]

We should support plugins, probably most useful for UI changes. There have been several suggested major changes or additions to the UI (as PRs). I'm hesitant to merge (or even getting them to a state to be mergable). In the past, some of those bigger merged PRs let to code that needed to be maintained by the "core team" and for other, they just go against my personal preferences. Having the ability to support plugins would solve those issues, as those UI changes could be supported by other parties out of tree.

Does anyone have experience with supporting plugins in python code bases? My first naive idea would be to load any python module placed in a specific directly, probably after all click related parts have been initialized.

[choucavalier]

i'm not sure exactly how to properly architecture khal's codebase to support plugins

are you suggesting that the plugin would modify or register new cli functionalities? not sure exactly how this can be done but it really makes me think of the pdbpp project which works by extending the Python debugger (pdb) without pdb explicitly supporting any "plugin". i think pdbpp just comes to slightly modify ("patching") pdb's code in some way? haven't looked at the code but it works out of the box and "replaces" (not really because it's just a better UX) pdb

[geier]

In #1279, I experimented with the "load all python modules in xdg_data_home/khal/plugins/ approach and at least for loading color themes it seems to work fine. Not sure yet how it would work with new (click) commands.

[geier]

Some python plugin frameworks:

• pluggy - the pytest plugin system
• stevedore - Manage dynamic plugins for Python applications
• yapsy - A fat-free DIY Python plugin management toolkit.

[choucavalier]

pluggy looks like the best option:

• good architectural system, according to the "How does it work" section of the main page of the documentation
• well maintained (commits every week)
• battle-tested by pytest, which is invaluable

[tcuthbert]

Some python plugin frameworks:

• pluggy - the pytest plugin system
• stevedore - Manage dynamic plugins for Python applications
• yapsy - A fat-free DIY Python plugin management toolkit.

I missed this!

I got a start on a very basic way of registering plugins, similar to how mdformat works (i.e. with global maps, callables and interfaces).

I wouldn't have thought too many third party plugins would be needed, making a plugin manager overkill, but I can see the value in less boiler plate.

I'm not attached to my work, happy to help integrate a 3rd party library too.

[geier]

@tcuthbert I'm also not attached to any of those frameworks.

[geier]

@tcuthbert
I have tried something very simple at #1309 and #1303 but I believe your approach using importlib is much smarter. I'll try to rebase #1309 and #1303 and the example plugins on your branch.

[geier]

I have merged @tcuthbert's and my work at #1312

[tcuthbert]

Excellent! I ended up starting a new job and lost all my free time to work on it.

…

On Mon, 30 Oct 2023, 12:45 am Christian Geier, ***@***.***> wrote: I have merged @tcuthbert <https://github.com/tcuthbert>'s and my work at #1312 <#1312> — Reply to this email directly, view it on GitHub <#1258 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA7LQLZMXMSPDNOGW2PHTBDYBZ23FAVCNFSM6AAAAAAYN6U67GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOBUGE3DGOJYGY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[geier]

Excellent! I ended up starting a new job and lost all my free time to work on it.

I hope, it's fun and pays well.