Quote:
Originally Posted by Rev. Bob
Y’know, if it comes to it, it might not be the worst idea in the world to treat the Python v3 port as a fork for the time being. That way, the still-current iteration would remain in place for 4.x users and the port could be restricted to 5.x. It’d probably require renaming the ported plugin and a couple of files (like the me.py CLI interface script) to avoid collisions, but it would mean not having to worry about Python v2 compatibility.
|
I am all for this. Anything I can do to give the PI back to you.
As for me.py, I don't think renaming is needed. There can (should) be only one version of the PI installed so there can't be name collisions. I think it sufficient to rename the PI in __init__. This will (I think) require new lines in the PI index and a new PI thread so the calibre plugin updater doesn't get confused. Keeping the current plugin-import-name-modify_epub.txt should permit keeping all the internal import statements. The only way to be sure is to try it.
How about "Modify Epub 5" for calibre 5 and up? Or "Modify Epub 2" for version 2?
Quote:
Then, perhaps, if circumstances merit it and the working v3 port can be made v2-compatible, either they could be merged or the v2 edition could formally be updated to the v3 port.
Basically, I’m considering options that (a) don’t break the plugin for anyone and (b) make a working version available on calibre 5 sooner. But remember that I’m speaking as a spectator on this process.
|
These are good reasons.
Another thing I am thinking about is modifying the plugin updater to support multiple zip files for a plugin. It would choose one that a) works in the running version of calibre and b) has the highest PI version number. This allows overlap between supported calibre versions.
In any event, I will look at all this tomorrow. Today is grandchildren day.
