Quote:
Originally Posted by KevinH
For small projects, I just change the plugin.py final "return 0" with "return -1" so that a full debug log is always created and nothing will ever get changed in Sigil by my plugin, then add a bunch of print statements, fire up Sigil and can launch my plugin again and again tweaking the plugin code as needed inside where it gets unpacked to in the Sigil Prefs folder. There is no need to delete or reinstall the plugin itself, and no need to even relaunch Sigil. Just a quick edit, run cycle.
|
Yes, that's mostly what I do myself during development!
Obviously, while the project grows, it becomes less and less rigorous.
Quote:
Originally Posted by KevinH
Sounds interesting! For larger projects, I typically unzip an epub into a "root" folder inside a new project folder, then copy all the plugin code itself and add the very minimum python code to invoke the launcher.py script properly.
I can easily see that a more rigorous test set-up outside Sigil itself might be valuable. The entire plugin interface is meant to be launched in a subprocess from within Sigil via the command line so it can be isolated away from Sigil. Just passing in the correct inputs and config file, setting paths, etc should be enough given an appropriate python3 setup is available.
.
Thanks!
|
So, by putting an unpacked epub in a folder, a properly filled 'sigil.cfg' file in another and then calling with appropriate arguments the function 'main' of the launcher.py module, I can launch a plugin outside of Sigil with a fully operational BookContainer object? That's very good to know!
The main rigidity with this approach is that you need to launch the whole plugin every time (unless you launch a different wrapper module every time, I guess...).
It sounds like if you put yours and my approach side by side, with some minor tweaks you could have both unit and functional testing capabilities at your disposal.
