Plugin Development

[KevinH]

The sys.path list can be appended to easily if done before importing a module, and the launcher wrapper has a self.appdir that will allow the path to the python3lib to be built on the fly easily (See EmbeddedPython.cpp embeddedRoot() routine - or something like that) on Windows and Mac. I am less sure where exactly on Linux the python3lib ends up depending on build settings.

So it would be easy to do with current code in a plugin on Windows and Mac, but I am not sure how easy it would be on Linux.

Diapdealer - is there any way to figure out where the python3lib is located in the current launcher or wrapper plugin code given what we pass in the sigil.cfg file?

[DiapDealer]

Originally Posted by KevinH

Diapdealer - is there any way to figure out where the python3lib is located in the current launcher or wrapper plugin code given what we pass in the sigil.cfg file?

Not really from that cfg info, no.

And there's not a completely straightforward other way considering how many different ways Sigil can be installed on Linux, I should probably add Sigil's support file root location (typically /usr/share/sigil or /usr/local/share/sigil) to PluginRunner's cfg file that gets parsed by wrapper.py. But until that happens, Sigil's support file root location could be literally anywhere. It can be changed at compile-time or runtime.

However ... I believe the "plugin_launchers/python" directory is already added to every plugin's sys.path. If that can be identified, the python3lib directory is always going to be ../../python3lib from that one.

Something in here should get someone going in the meantime.

import sys, os

for path in sys.path:
    if "plugin_launchers/python" in path:
        print(path)
        sys.path.append(os.path.join(path, '../../python3lib'))
        print(sys.path)
        break
try:
    import ncxgenerator
    print('python3lib path', os.path.dirname(os.path.abspath(ncxgenerator.__file__)))
except ImportError:
    print('Can\'t find python3lib')

[Doitsu]

@DiapDealer: Thanks for the code! After some cosmetic changes, it seems to work on all three platforms:

#!/usr/bin/env python
# -*- coding: utf-8 -*-
import sys, os

def run(bk):
    print(sys.path)
    for path in sys.path:
        if "plugin_launchers/python" or "plugin_launchers\\python" in path:
            print(path)
            sys.path.append(os.path.normpath(os.path.join(path, '../../python3lib')))
            print(sys.path)
            break
        
    try:
        import ncxgenerator
        print('python3lib path', os.path.dirname(os.path.abspath(ncxgenerator.__file__)))
    except ImportError:
        print('Can\'t find python3lib')
        
    return 0

def main():
    print('I reached main when I should not have\n')
    return -1

if __name__ == "__main__":
    sys.exit(main())

[DiapDealer]

Great! Glad it works. If you don't want to loop though sys.path on Windows/Mac, remember that python3lib will always be:

os.path.join(bk._w.appdir, '../python3lib') -- for Mac
os.path.join(bk._w.appdir, 'python3lib') -- for Windows.

[Doitsu]

Originally Posted by DiapDealer

Great! Glad it works. If you don't want to loop though sys.path on Windows/Mac, remember that python3lib will always be:

os.path.join(bk._w.appdir, '../python3lib') -- for Mac
os.path.join(bk._w.appdir, 'python3lib') -- for Windows.

Thanks again for the updated code!



I'll add it in the next version of the plugin.

[DiapDealer]

I'll try to make sure and test the strategy on Linux with Sigil built/installed/and run in a variety of the possible configurations.

[Doitsu]

@DiapDealer @KevinH

I'm working on a barebones edit plugin that'll delete unmanifested files from the Temp folder. It appears to be working fine. However, since deleting files in the Temp folder can crash Sigil, I'd appreciate it, if you could check the code.

EDIT: Unsupported and possibly dangerous code deleted.

[DiapDealer]

It looks to be OK at first glance. You may want to add a try/except clause around the os.remove() call so that it can fail gracefully, though. An exception will be raised on Windows if the file in question happens to be open. Better safe than sorry.

Also ... I'm sure there's probably more "allowable" unmanifested files that will only become apparent after you've released your plugin (not that I can think of any offhand). A way for the user to exempt specific files (or file-types) might stave off future trouble.

[Doitsu]

Originally Posted by DiapDealer

It looks to be OK at first glance. You may want to add a try/except clause around the os.remove() call so that it can fail gracefully, though.

That's a god idea. I'll add a try/except clause to check for locked backup files.

Originally Posted by DiapDealer

A way for the user to exempt specific files (or file-types) might stave off future trouble.

I can't think of any other "allowable" unmanifested file types. If this actually becomes an issue, I'll add a setting for it. (I don't think that the plugin'll be widely used anyway.)

[DiapDealer]

Originally Posted by Doitsu

I can't think of any other "allowable" unmanifested file types. If this actually becomes an issue, I'll add a setting for it. (I don't think that the plugin'll be widely used anyway.)

Fair enough.

[Doitsu]

Currently, it's pretty much impossible to get the name of currently opened file with Python. Some time ago, I investigated a rather complicated and not very reliable Windows-only method.

Since a Plugin Runner code update probably wouldn't be easy, I'm wondering about a different approach: would it be possible to have Sigil write the name of the epub file to the recentfile sigil.ini entry upon opening the epub file?
Plugin developers could then simply parse sigil.ini with configparser to get the file name. Since Sigil writes the file name to sigil.ini anyway whenever a file is closed this shouldn't require major code changes.

[KevinH]

The plugin runner actually builds a sigil.cfg file that the plugin launcher code parses to get appdir, dictionary and other paths for the wrapper code that are then added to the plugin interface. The correct way to handle this is to change MainWindow.cpp to add a routine to access m_CurrentFilePath, and use that new interface in PluginRunner to add this new path to the sigil.cfg and then add associated interface routines to the launcher/wrapper and then plugin type specific codes.

This involves quite a bit of work. So please explain why it is needed? Is this just to seed a possible name for output plugins? Why would an edit plugin need to know the name of the epub file as it can not be changed without messing up Sigil. Ditto for a validation plugin?
And input plugins are to load other files anyway so the current filename does not make much sense to me there either.

Kevin

[Doitsu]

Originally Posted by KevinH

So please explain why it is needed? Is this just to seed a possible name for output plugins?

It'd be a nice-to-have feature for output plugins, but since it apparently would require a lot of work, it'd be better, if you used your limited time to work on enhancements.

[KevinH]

Wouldn't it be easier to recommend to users they add an html comment to the first file or define display:none header with the filename in the first file, or add a metadata element to the opf with that info and then invoke the output plugin? Your plugin could easily determine if the user has done this and if so read and use it otherwise default to a generic output filename.

Alternatively, parse the opf to get the main book title and remove unwanted/unsafe chars from it and use that as a suggested title.

[Doitsu]

This may be a stupid question: is it possible to explicitly import book container functions such as bk.sigil_ui_lang() before run(bk) is executed?

If yes, what's the import declaration?