Removing a Plugin and its dependencies

[tmiranda]

I recently had an issue that was caused by a misbehaving plugin. More specifically, a misbehaving plugin dependency. I noticed there is no way from the plugin manager to uninstall a plugin AND all of its (unneeded) dependencies so I started thinking about writing a plugin to do this. Looking at the PluginAPI I don't see any methods that tell me what dependencies a plugin has or if an installed plugin is a dependency of another installed plugin.

Did I miss something? If not I plan on making a feature request to Sage. (I really don't want to write an XML parser.)

Tom

[PLUCKYHD]

My 2 cents make the request to sagetv anyhow this should be a default feature when uninstalling a plugin.

[stuckless]

Originally Posted by tmiranda

I recently had an issue that was caused by a misbehaving plugin. More specifically, a misbehaving plugin dependency. I noticed there is no way from the plugin manager to uninstall a plugin AND all of its (unneeded) dependencies so I started thinking about writing a plugin to do this. Looking at the PluginAPI I don't see any methods that tell me what dependencies a plugin has or if an installed plugin is a dependency of another installed plugin.

Did I miss something? If not I plan on making a feature request to Sage. (I really don't want to write an XML parser.)

Tom

Well, the good news, is that you won't have to write an xml parser, since java has one built in (jaxp)... unless you meant, write a tool to parse the plugin dependencies xml??

I brought this up some time ago as well.. i can remember if it was a private email or forum posting, but I didn't see anything at time to get a recursive list of dependencies.

It would be handy to simply select something like BMT and and then click completely uninstall and it would inform you of all the plugins that would have to be removed to completely remove bmt and it's dependencies. Unfortunately there is nothing in the PluginAPI about dependencies

[vividweb]

After having to try and fix some plugins, the ability to remove a plugin and its dependancies should be available.

[GKusnick]

Originally Posted by stuckless

Unfortunately there is nothing in the PluginAPI about dependencies

Sure there is. GetPluginDependencies(plugin) gives you the PluginIDs of all plugins on which the given plugin depends. I've used this to implement a number of dependency-checking extension methods in my PluginAPI wrapper class. In principle this is all the information you would need to iterate over installed plugins to find the ones on which no other plugins depend.

The real trick is deciding whether it's OK to uninstall them. Suppose the user installs plugin A, which pulls in B as a dependency. Suppose also that B provides some useful feature of its own that the user then comes to rely on. In that case, automatically removing B when A is uninstalled would not necessarily be what the user wants. It's even possible that the user manually installed B first, and then A, and wants to keep B when A is removed. There's no way to distinguish these cases just by examining dependencies. So the only time it would really be safe to remove B is if B is a pure library plugin that exposes no user-level behavior at all (in which case it does no harm to leave B installed).

[stuckless]

Originally Posted by GKusnick

Sure there is. GetPluginDependencies(plugin) gives you the PluginIDs of all plugins on which the given plugin depends. I've used this to implement a number of dependency-checking extension methods in my PluginAPI wrapper class. In principle this is all the information you would need to iterate over installed plugins to find the ones on which no other plugins depend.

The real trick is deciding whether it's OK to uninstall them. Suppose the user installs plugin A, which pulls in B as a dependency. Suppose also that B provides some useful feature of its own that the user then comes to rely on. In that case, automatically removing B when A is uninstalled would not necessarily be what the user wants. It's even possible that the user manually installed B first, and then A, and wants to keep B when A is removed. There's no way to distinguish these cases just by examining dependencies. So the only time it would really be safe to remove B is if B is a pure library plugin that exposes no user-level behavior at all (in which case it does no harm to leave B installed).

Looks like I missed that API... Thanks.

I agree that you'd have to be careful, which I why I would propose that any plugin that would do this this... should actually present the user with the complete list of plugins that would be removed before the remove is actually done... ie, like most package managers under linux.

Ideally the "uninstall" would have 2 buttons.. "uninstall" and "completely remove". The latter would prompt you with a dialog showing a complete list of plugins that need to be removed, giving you a chance to continue, or abort.

Just for the record... i don't intend on writing this... but it is good to know, as Greg pointed out, that the APIs are there, in case someone else wants to do it.

[stuckless]

Greg, now I remember why GetPluginDependencies doesn't work... because it doesn't return a list of plugin ids, but rather a list of descriptions...

Returns an array of Strings which specifies the dependencies of this plugin. These strings will be descriptive and indicate the type of dependency (i.e. STV, Plugin, OS or Desktop) and the specifics of that dependency.

I thought I must have been losing my mind, because i knew I had this conversation with Narflex before aobut how handy it would be get let a list of plugin dependencies... His comment, if I recall, is that you can potentially scrape the output of GetPluginDependencies... which I wasn't prepared to do.

[GKusnick]

Originally Posted by stuckless

Greg, now I remember why GetPluginDependencies doesn't work... because it doesn't return a list of plugin ids, but rather a list of descriptions...

I thought I must have been losing my mind, because i knew I had this conversation with Narflex before aobut how handy it would be get let a list of plugin dependencies... His comment, if I recall, is that you can potentially scrape the output of GetPluginDependencies... which I wasn't prepared to do.

Yes, you're right; I'd forgotten that part. But looking back at my code I have in fact done that conversion to a list of PluginIDs. So the information is there and in a usable form (if you use my API wrappers).

[tmiranda]

Thanks for the pointers. I didn't realize I could use the String[] from GetPluginDependencies to find the Plugin Object, now I see how to do that.

I'm going to look into this a little more because I think it's a worthwhile plugin to have available. It's probably something that should really be done in the Sage Core.

Tom

[tmiranda]

Originally Posted by stuckless

I agree that you'd have to be careful, which I why I would propose that any plugin that would do this this... should actually present the user with the complete list of plugins that would be removed before the remove is actually done... ie, like most package managers under linux.

Ideally the "uninstall" would have 2 buttons.. "uninstall" and "completely remove". The latter would prompt you with a dialog showing a complete list of plugins that need to be removed, giving you a chance to continue, or abort.

I've started working on this and this is the direction I'm going. When you select "completely remove" you see a list of all the dependencies with an indicator showing if it will be uninstalled or won't (because it's a dependency for another plugin.) For each dependency that will be uninstalled you can manually override the uninstall.

I'm just starting on this and suspect it will not get done real soon because Slugger and I are getting ready to release SJQv4.

[stuckless]

Originally Posted by tmiranda

I've started working on this and this is the direction I'm going. When you select "completely remove" you see a list of all the dependencies with an indicator showing if it will be uninstalled or won't (because it's a dependency for another plugin.) For each dependency that will be uninstalled you can manually override the uninstall.

I'm just starting on this and suspect it will not get done real soon because Slugger and I are getting ready to release SJQv4.

I think it will be a great plugin. Good luck.

[tmiranda]

It's still in the deisgn phase. Lots of things to think about: dependencies of dependencies, circular depencies, order of plugin removal, failure recovery, etc. I think it will be fun.

[GKusnick]

Originally Posted by tmiranda

...circular depencies...

I'm pretty sure circular dependencies are detected and flagged as errors by the plugin submission script. So there shouldn't be any circular dependencies in the repository or on normal end-user installations.

On the other hand it's probably possible to abuse SageTVPluginsDev.xml to create circular dependencies locally on your dev machine.

[PLUCKYHD]

Originally Posted by GKusnick

I'm pretty sure circular dependencies are detected and flagged as errors by the plugin submission script. So there shouldn't be any circular dependencies in the repository or on normal end-user installations.

On the other hand it's probably possible to abuse SageTVPluginsDev.xml to create circular dependencies locally on your dev machine.

I don't think they are detected by the plugin system. But if you do one like on a local dev (i did once by mistake) you will get hung when trying to install. Just the tainted circle of death

[tmiranda]

Originally Posted by GKusnick

I'm pretty sure circular dependencies are detected and flagged as errors by the plugin submission script. So there shouldn't be any circular dependencies in the repository or on normal end-user installations.

On the other hand it's probably possible to abuse SageTVPluginsDev.xml to create circular dependencies locally on your dev machine.

I've verified that both of these statements are true.

[tmiranda]

So here it is: http://forums.sagetv.com/forums/showthread.php?t=53047

I had to brush off my recursive programming skills for this so if you find bugs please let me me know.