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

More thoughts on dynamic plugin loading #221

Open
mgrandi opened this issue Oct 27, 2023 · 1 comment
Open

More thoughts on dynamic plugin loading #221

mgrandi opened this issue Oct 27, 2023 · 1 comment

Comments

@mgrandi
Copy link

mgrandi commented Oct 27, 2023

Hello!

I looked at the code for my work hackathon to see if i could write a Pinpoint plugin in a separate repository, after you committed your initial plugin support here: #204

Some thoughts:

The main idea at least in my mind is the ability to write a plugin in a separate repo without having to have it in the main Pinpoint repository, which makes updating your plugin when Pinpoint updates much easier so you don't have to worry about rebasing

the current issue with your implementation is that while it seems to work fine for plugins that are in the same repository, (with the abstract plugin class: https://github.com/dkgv/pinpoint/blob/master/Pinpoint.Core/AbstractPlugin.cs ) , there is no way to write a plugin that lives outside of the Pinpoint repo that can access the necessary classes. You MIGHT be able to copy the classes to your own project, but that introduces drift, and i'm honestly not too sure what happens if you have ClassA and ClassB that are the same class source code but compiled separately (in the main Pinpoint process and in a theoretical external plugin)

you mentioned in this PR #214 that you have some plans to rework the core of Pinpoint, maybe this can be part of that effort

Also to note: there should also probably be some sort of 'version' communication, as in making sure that a plugin returns that it supports up to Version X of pinpoint so that way changes to the interface don't break anything about the plugin

In short, i think the "core" classes need to be separated from the UI, and there needs to be like a Pinpoint.Interfaces project that is published to Nuget , so that way a external plugin can that package, and use the interfaces to develop their plugin, and then the Pinpoint source code can just use a to "Pinpoint.Interfaces" or whatever and that will act as a 'implicit' PackageReference (as long as every proper release of Pinpoint has a nuget package publish as part of that)

But the code for loading the plugin from the Plugins folder seems to be working as it worked as expected for my in development plugin

@dkgv
Copy link
Owner

dkgv commented Nov 19, 2023

Hey!

I agree, I was actually planning on something like this after my initial changes in #204 but never got around to it.

I'm currently leaning towards keeping all projects within this repository but then adding a new Pinpoint.Plugin project that holds the relevant interfaces. This can then be published and referenced as a standalone NuGet package which should enable plugin development in the manner we want.

So, I just had a cup of coffee and did the groundwork in #224 👍

Also, I agree with your thoughts on plugin versioning but I'll leave that for another time.

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

No branches or pull requests

2 participants