@kiwidude
For the handling of newly integrated plugins as the updater you could invent a routine. What should this routine do?

On first start after installation (or with every start depending if the second routine doesn't exists) check if a deprecated plugin has been installed.

deinstall the deprecated plugin/s

give message of deinstallation

restart Calibre

The second routine is part of the updater, it checks if the deprecated function is to be installed and denies installation and gives error message.

I know, this is only possible if the plugins are installed under their official names, but I assume that nearly everyone will have them installed this way. The last remaining are just calculated losses.

I vote for NOT putting the Plug-ins into Main Calibre as it will limit PI repair to the release cycle (waiting a week is H*ll )
OTOH If it is only the Distribution of the PI that is included with a normal release, then relocating (and maybe applying a visual 'style' to the label that indicates a normal part of Calibre) makes manual, Mid-Release (of Calibre) PI upgrades available.

I vote for NOT putting the Plug-ins into Main Calibre as it will limit PI repair to the release cycle (waiting a week is H*ll )
OTOH If it is only the Distribution of the PI that is included with a normal release, then relocating (and maybe applying a visual 'style' to the label that indicates a normal part of Calibre) makes manual, Mid-Release (of Calibre) PI upgrades available.

Why would he put plugin update into calibre if plugins won't be updated separately

@Loeffel - the theory of it sounds good but I'm not sure how easy it is to implement in terms of the timing of plugins being loaded into Calibre, in-built versus custom plugins, handling of duplicate names etc. I'm hoping Kovid can share his insight/experience on that as to what would "work" with the current code and obviously support a change if it is thought appropriate to do so.

@theducks - haha, too funny. You know you could run from source if you don't want to wait a week, right? Besides, you guys are lucky that I have been taking a break from work for a while to put these plugin updates out so frequently. That will definitely change once I start work again. Plus by being in Calibre it means there is the possibility (however remote since all are busy with their own stuff) other Calibre developers could work on any fixes/additions rather than it just being the original plugin developer. So it wouldn't all be bad...

And yes it is only Plugin Updater and Find Duplicates that I personally see being directly added to Calibre sooner rather than later.

Why would he put plugin update into calibre if plugins won't be updated separately

Because there are people running really down rev versions of Calibre who don't update because of system dependency issues (I assume the OS upgrade would destroy a really expensive, mission critical piece of software with no (free) updates available) (Why would they be running Calibre on a Mission critical system in the first place?)

@theducks - haha, too funny. You know you could run from source if you don't want to wait a week, right? Besides, you guys are lucky that I have been taking a break from work for a while to put these plugin updates out so frequently. That will definitely change once I start work again. Plus by being in Calibre it means there is the possibility (however remote since all are busy with their own stuff) other Calibre developers could work on any fixes/additions rather than it just being the original plugin developer. So it wouldn't all be bad...

I could never get it (RFS) to work on my XP system (no astirisk). chaley coached me, too

1) Ignore any user plugins that have the same name as a builtin plugin, so if a future calibre release gets a builtin plugin with the same name as a user plugin, the user plugin will be ignored. Not only that, the plugin will be silently uninstalled (this is for performance, so that the plugin zip file is not unnecessarily read at each calibre startup)

2) Popup an error message if a user tries to add a plugin with the same name as a builtin plugin

@kiwidude: I'd appreciate it if you could test these two changes as I am rather busy at the moment.

They will handle the situation of a plugin like "Plugin Updater" or "Find Duplicates" becoming part of Calibre nicely, and in that situation it will be appropriate to remove the plugin from the forum plugin index page completely so it will not appear in the plugin updater dialog.

However there is still the other scenario of where a plugin gets renamed or combined into a new plugin. The most recent example is "Kindle Collections" which was previously known as "Create Kindle Collections". I will shortly have an additional scenario of "Goodreads Metadata" and "Goodreads Covers" being replaced by a new metadata source plugin called "Goodreads".

I have made the changes to plugin updater to support a "Deprecated" value on the index page, and placed an additional greyed out section on the plugin index page at the bottom where such plugins will go to "die".

With the changes I have made, if it sees that you have one of these plugins installed, it gets a special icon and appearance as per the attached screenshot. It will show up on the "All", "Update available" and "Installed" views. If you either (a) install it's replacement using Plugin Updater, or (b) uninstall it, then it disappears and will never be visible again on the plugin updater dialog (well unless you reinstalled it manually outside of plugin updater).

I have also added support for multiple uninstall plugin targets, so my Goodreads plugin will have "; Uninstall: Goodreads Metadata,Goodreads Covers" on the index page and both those plugins will get uninstalled. [Note that I will only put that attribute on there when Calibre 0.8 is officially released, as it is valid to have all plugins side by side for users who are just temporarily testing both].

Before I push the new Plugin Updater version, any objections to the above?

@Nyssa - depends on your definition of "prompt" but yes, it is a visual warning that you should uninstall it. And in normal usage of the plugin updater (such as installing its replacement) that uninstall will happen automatically. The text that will appear in the description field will tell the user exactly why the plugin has reached this warning state and what they should do about it (such as the name of the replacement plugin or whatever).

I don't want such upgrades to happen automatically because there are people who want to be conservative in upgrading and not necessarily grabbing the latest as soon as it is available. This was the best compromise I could think of to keep the user informed without having plugins disappearing without them knowing why.

@Nyssa - depends on your definition of "prompt" but yes, it is a visual warning that you should uninstall it. And in normal usage of the plugin updater (such as installing its replacement) that uninstall will happen automatically. The text that will appear in the description field will tell the user exactly why the plugin has reached this warning state and what they should do about it (such as the name of the replacement plugin or whatever).

I don't want such upgrades to happen automatically because there are people who want to be conservative in upgrading and not necessarily grabbing the latest as soon as it is available. This was the best compromise I could think of to keep the user informed without having plugins disappearing without them knowing why.

Quote:

Originally Posted by kiwidude

Yes the tooltip tells you, as well the description for the plugin at the bottom.

The problem is that I already use grey for disabled plugins. Or do you want a compromise of the red icon with grey text?

Okay. Cool. It seems like you have all angles coverd, with both a visual cue and an explanation.

Quote:

Originally Posted by kovidgoyal

Use another color, blue perhaps? After all having a deprecated plugin is not a critical condition, so red seems a little excessive

As an end-user, red would catch my attention more than blue, although I do understand your point of it being a non-critical issue.

Since you will be using blue, please make sure there is a color key added somewhere where the average end-user is likely to read it.

Thank you both so much for all of your hard work! I can not put into words my appreciation for Calibre, its team of developers and those who volunteer their talents. Thank You.