Skip to content
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

Closed
wants to merge 12 commits into from
Closed

Plugin support #975

wants to merge 12 commits into from

Conversation

rxt1077
Copy link
Contributor

@rxt1077 rxt1077 commented Mar 10, 2022

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.

@xcoulon
Copy link
Member

xcoulon commented Mar 13, 2022

thanks for this PR @rxt1077
I need to take a closer look at Go plugins, since they seem to have quite a few limitations :/
Also, could you include some tests to show and verify how it works? This may require some additional goals in the makefile, though 🤔

@rxt1077
Copy link
Contributor Author

rxt1077 commented Mar 14, 2022

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.

@rxt1077
Copy link
Contributor Author

rxt1077 commented Mar 15, 2022

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.

@rxt1077 rxt1077 closed this Mar 16, 2022
@xcoulon
Copy link
Member

xcoulon commented Mar 16, 2022

ok, thanks for the update and for all the time you spent on this, @rxt1077
I haven't tried go-plugin yet, but I will try to give it a look as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants