-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Plugin support #975
Plugin support #975
Conversation
thanks for this PR @rxt1077 |
Thanks and I understand. Go plugins do seem limited and it's worth exploring other options. This is less of a "best" solution and more of a "possible" solution. I appreciate you taking a look and please don't feel pressured towards any action. I'll see if I can create some tests, I realize that part of my PR is missing. |
I wrote an example plugin, changed the make recipes to compile it, and added tests for loading a plugin. Despite that, it seems that I can't load plugins from the ginkgo tests without having the exact same runtime as the rest of the library. I'm not entirely sure when/how the ginkgo tools are compiled. At this point I'm almost 100% sure that golang native plugins aren't the best solution for this. They seem to make it too difficult for other contributors to write plugins that can be loaded. They really seem to be meant to be exclusively used in-tree in very large projects. Unless there are any objections, I'm going to close this PR and try again using go-plugin, which basically serves golang interfaces over local RPC. It seems like a much better way of doing it. |
Addresses #974.
This is a rudimentary version of plugin support for libasciidoc. It adds a command-line option to the binary and runs a PreRender function from plugins just before the document is rendered. Plugins are golang plugins with the
PreRender
symbol exported.