We have discussed builting the carbon-txt validator to:
be a standalone piece of software from the green web platform
have a usable plugin system so that the core logic is something others can use while allowing us some clear places to extend if ourselves
Using a hook based plugin system
After some internal discussion , we've decided to go for a hook based approach. This is the approach used by a number of hugh profile projects.
Both Wordpress and Drupal both have a hook based approach for allowing third party code to hook into existing functionality.
In the python ecosystem, Pytest, the dominant testing framework relies on a popular and battle tested plugin system called Pluggy and there are tens of plugins using this system to refer. Two other open source projects make heavy use of it too Datasette, which has a nice plugins directory and LLM which also has a nice tutorial for making new plugins.
Acceptance criteria
i.e. how will we know when this is done?
[ ] We have an Architectural Decision Record in the codebase summarising now it would work, plus the consequences, positive and negative, of our approach.
[ ] We have implemented a minimal number of plugin hooks (likely: one for registering a plugin, one to call when a specific document type is discovered in a carbon.txt file, and one when a document type is being validated)
[ ] We have a one example implementation of the chosen hooks in a plugin. This does not need to be a plugin in a separate package, as most plugin systems are agnostic of whether a hook is in the same file, the same main code module, or external module downloaded from the internet. This plugin would not be the CSRD plugin - it would be a minimal one, that does something useful, like run an HTTP check that a publicly resource is returning a 200, for example, or simply log itself being called by the plugin system, like the minimal Hello Dolly plugin with wordpress
[ ] We have a documentation page on how to implement the exposed hooks, for making new plugins.
Background
We have discussed builting the carbon-txt validator to:
Using a hook based plugin system
After some internal discussion , we've decided to go for a hook based approach. This is the approach used by a number of hugh profile projects.
Both Wordpress and Drupal both have a hook based approach for allowing third party code to hook into existing functionality.
In the python ecosystem, Pytest, the dominant testing framework relies on a popular and battle tested plugin system called Pluggy and there are tens of plugins using this system to refer. Two other open source projects make heavy use of it too Datasette, which has a nice plugins directory and LLM which also has a nice tutorial for making new plugins.
Acceptance criteria
i.e. how will we know when this is done?
Related work and helpful references
https://pluggy.readthedocs.io/en/ https://medium.com/@garzia.luke/developing-plugin-architecture-with-pluggy-8eb7bdba3303 https://docs.datasette.io/en/stable/writing_plugins.html https://simonwillison.net/2022/Aug/17/datasette-lite-plugins/ https://simonwillison.net/tags/plugins/