Open mvandeberg opened 7 years ago
I'm also going to add it to CI
How exactly do we want to it to be a part of CI?
Have the Dockerfile
run newplugin.py
to generate a dummy
plugin and make sure it builds. Do it for one of the testnet targets only, so we don't clutter release binaries with an unused plugin.
The main purpose is so that when we make breaking changes to the plugin API, the person that made the breaking change is required by CI to update the template in the same PR.
It's much better than the current workflow, which is whenever there are breaking changes to the way plugins work, weeks - months down the road the next time it's decided a new plugin is needed, the person creating the plugin discovers the skeleton generated by newplugin.py
doesn't quite work, and then has the Fun of digging into why.
I personally have never used the script to generate a new plugin and forgot it even existed until you asked about it during code review. I will likely still never use it. Especially now that everything is a plugin, we really need multiple plugin templates. A base template, and API template, a non-consensus state template, etc. I feel that I am more likely just to copy a plugin that works similarly to what I want to do and change what is different and update a plugin template will be an annoyance if we need to update the plugin interface in the future.
This is actually a fairly extensive refactoring. Also I want to update from Python format strings to jinja2
templates, since jinja2
is now required by our build process anyway.
I'm keeping my assignment for now because I'm halfway through this task.
The new plugin template needs to be updated for appbase plugins