Plugin Removal

[BetterRed]

When a plugin is removed, the zip is deleted but associated files are not.

I appreciate the reason why one might not want them deleted, but IMO the option to do so should be available.

I just removed the Open With PI, because I now use the built in Open With feature exclusively. That left 'Open With Help.htm' and 'Open With.json' in the <configuration>\plugins folder. I knew that would happen... but I suspect a good many users wouldn't... so I removed them manually.

I know it 'doesn't matter' and the disk space used is immaterial, but if at a later date someone had a problem with the built in Open With feature they could get confused. Besides, IMO its bad practice to leave dross lying around on computers, just as it is on mine sites.

Windows programs often have an option in their 'Uninstall' to delete/retain the settings, including programs that don't store settings in the registry. So on that platform at least, the question 'Also remove configuration data?' would not be out of line with 'common' practice.

BR

[DiapDealer]

Calibre doesn't know all the pecifics about plugin configuration and/or support files. Only the plugin itself would know all the details necessary to remove itself entirely. I suppose it wouldn't be impossible to create a cleanup framework that calibre could run at plugin removal time, but it would still be entirely up to the plugin developer to provide a valid manifest for that cleanup routine. Sounds like a lot of work for something that couldn't really be enforced anyway.

Don't get me wrong, I'm not opposed to a cleanup option, I'm just not sure it could be accomplished short of calibre monitoring every run of every plugin to record any files that might get created by plugins.

[BetterRed]

Originally Posted by DiapDealer

Calibre doesn't know all the pecifics about plugin configuration and/or support files. Only the plugin itself would know all the details necessary to remove itself entirely. I suppose it wouldn't be impossible to create a cleanup framework that calibre could run at plugin removal time, but it would still be entirely up to the plugin developer to provide a valid manifest for that cleanup routine. Sounds like a lot of work for something that couldn't really be enforced anyway.

@DiapDealer - Why couldn't the PI removal framework invoke an 'uninstall_cleanup' method within the PI (assuming it exists). That would put the onus on the PI to know about its dross files rather than the framework itself. Obviously the PI developers would have to add the uninstall_cleanup method to relevant PI's - at their convenience.

I'm blissfully ignorant of calibres PI framework - so "BetterRed, that's not the way calibre PI's work, or that's hard to do in python, etc" are acceptable answers.

BR

[DiapDealer]

Originally Posted by BetterRed

@DiapDealer - Why couldn't the PI removal framework invoke an 'uninstall_cleanup' method within the PI (assuming it exists).

It could, but it doesn't (because the method doesn't currently exist).

Originally Posted by BetterRed

That would put the onus on the PI to know about its dross files rather than the framework itself. Obviously the PI developers would have to add the uninstall_cleanup method to relevant PI's - at their convenience.

Yep. Certainly doable ... but that would still leave the user that wasn't aware those files were hanging around in the first place (and every user for that matter) at the mercy of 1) the PI dev who didn't take the time, or 2) the PI dev who didn't do it correctly/completely (or just forgot to update the uninstall_cleanup routine to accommodate later modifications to the plugin).

Originally Posted by BetterRed

I'm blissfully ignorant of calibres PI framework - so "BetterRed, that's not the way calibre PI's work, or that's hard to do in python, etc" are acceptable answers.

That's not the way calibre plugins work right now. Python itself certainly isn't a limiting factor in making the plugin framework work like that (though I won't pretend to speculate how "hard" it would be to implement). I just don't see a lot of incentive for someone to spend time creating what—at best—would essentially be a "check here to maybe/sorta cleanup some extra files this plugin may have created ... or not" box.

If it's not authoritative and automatic (when choosing the 'Also remove configuration data?' option), I don't see the point of including it. And I don't see a way of making it entirely authoritative and automatic (without extensive plugin process monitoring/logging).

[BetterRed]

Originally Posted by DiapDealer

I just don't see a lot of incentive for someone to spend time creating what—at best—would essentially be a "check here to maybe/sorta cleanup some extra files this plugin may have created ... or not" box.

I don't want to belabour the point - but in my imaginary pseudo C implementation, the question to the user would be raised by the PI not by the framework.

The framework would have

removePlugin(pluginSelected)
{
    ...
    if (pluginSelected.removalCleanup != null)
        pluginSelected.removalCleanup();
    ...
}

The plugin would have

removalCleanup()
{
    ...
    if (askQuestion("Remove the dross?") == true)
    {
          remove myJsonFile();
          remove myHelpFile();
          ...
    } 
    ...
}

But clearly it's not going to happen, so as my great grandfather would say... san fairy ann

BR