dkgv
commented
8 months ago 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.
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: https://github.com/dkgv/pinpoint/issues/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 https://github.com/dkgv/pinpoint/issues/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