How to solve shared files/dependencies across different plugins? #21
Comments
|
Option 1: When installing plugin, take a list of all extracted files. When uninstalling, remove only those not used by any other plugin. Cons: Requires additional file, not NuGet standard. |
|
I think this is a complex problem. I think we may need to adjust where plugins live, e.g. the standard plugins (i.e. those shipped with the official release) will live under Plugins\official (the name can change) and other plugins will live under own named folders (e.g. Plugins\AppVeyorIntegration). /cc: @sharwell @KindDragon @jbialobr @gerhardol @drewnoakes thoughts? |
|
Restricting the discussion to assembly/package references for a moment, can we reasonably detect and report such conflicts when scanning for plugins? Does MEF have anything to say about this? |
|
@RussKie +1 for plugin-per-folder structure. It can solve this issue for PluginManager. @drewnoakes Unsigned VSIX suffer from this too, as two plugins can't use two different versions of the same assembly. For detecting possible problems, PluginManager can detect if such dependency in other version is already installed, so user can be notified. |
|
How big is the need for handling plugins outside of GE core? "Private" plugins can be handled by private builds. |
|
Private builds built separately will introduce assembly version clashes.
This discussion is about how we can mitigate the risk.
…On Mon, May 28, 2018, 6:12 AM Gerhard Olsson ***@***.***> wrote:
How big is the need for handling plugins outside of GE core?
Should we spend time on this?
"Private" plugins can be handled by private builds.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<https://github.com/maraf/GitExtensions.PluginManager/issues/21#issuecomment-392362764>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AEMyXiiQN3pczGcQmKkMDMHyAHk2Z8LSks5t2wi0gaJpZM4UO9D->
.
|
|
Official support for plugins via MEF is non-trivial for development and distribution strategies. I would not recommend pursuing it at this stage unless it became a primary adoption requirement, and even then it would require some long discussions about the impact to overall development. |
|
Are you able to clarify why?
What would be a better/preferred strategy?
…On Mon, May 28, 2018, 2:14 PM Sam Harwell ***@***.***> wrote:
Official support for plugins via MEF is non-trivial for development and
distribution strategies. I would not recommend pursuing it at this stage
unless it became a primary adoption requirement, and even then it would
require some long discussions about the impact to overall development.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<https://github.com/maraf/GitExtensions.PluginManager/issues/21#issuecomment-392414377>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AEMyXiF01l1xIrGG9rIm_Pi1SdOgb_Jsks5t23m4gaJpZM4UO9D->
.
|
|
@RussKie We would need to strictly control the public API (by making everything internal until it passes API review), and then once something is made public we can't change it's behavior even if we change our mind in the future about how things should work. Then we need to rigorously apply a versioning policy for assembly names and use binding redirection to ensure future source and binary compatibility. The best strategy is to not support the area at all. It's difficult and time consuming to get right, and anything else will fall on the floor a year or so after you start (if you aren't strict about versioning, it still takes a bit of time to realize how serious the impacts are because most approaches work at least for a short while). |
What I meant is that if someone adds "PluginX", they can include the plugin in their private build of GE including the plugin until it is included in GE. I rather see that the limited GE resources are spent on features that improves GE. A monolith is in most cases simpler to move forward than a flexible structure. |
|
Sam, I agree with you to a certain extent. However I personally don't see
it as a major deal breaker.
A plugin is designed for a particular version of GE, which provides a
public API for integration.
If we decide to change the public API in the next version and a plugin
fails - the plugin author will need to release a new version compatible
with the new version of GE.
That's how VS is doing it, isn't it?
…On Tue, May 29, 2018, 12:03 AM Sam Harwell ***@***.***> wrote:
@RussKie <https://github.com/RussKie> We would need to strictly control
the public API (by making everything internal until it passes API review),
and then once something is made public we can't change it's behavior even
if we change our mind in the future about how things should work. Then we
need to rigorously apply a versioning policy for assembly names and use
binding redirection to ensure future source and binary compatibility.
The best strategy is to not support the area at all. It's difficult and
time consuming to get right, and anything else will fall on the floor a
year or so after you start (if you aren't strict about versioning, it still
takes a bit of time to realize how serious the impacts are because most
approaches work at least for a short while).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<https://github.com/maraf/GitExtensions.PluginManager/issues/21#issuecomment-392535859>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AEMyXqUE2qydHqeu_YvvGx8prD_7TpfFks5t3APJgaJpZM4UO9D->
.
|
|
I'm going to close this as there is no related work right now. |
No description provided.
The text was updated successfully, but these errors were encountered: