How to log within plugin?

[charlweed]

I'm trying to write my first plugin, and I'm surprised that logging does not work as expected. My plugin will "download" metadata, so I'm subclassing "Source"

I think "identify" is called and runs, but when I run callibre-debug -g nothing appears on the console from my method. The download Metadata dialog does not show anything either. I've searched my Windows computer for log files, but I can't find anything from Calbre.

    def identify(self, log, result_queue, abort, title=None, authors=None, identifiers=['series'], timeout=30):
        log.info('Authors: %s'%authors))
        log.info('Hello World!')        
        log.error('Hello World!')     
        return None

I've tried "str('hello world')" and I cannot find that output either.

Thanks for any help!
P.S. This is my first experience with Python too.

[kiwidude]

Two choices when it comes to metadata download plugins (assuming Windows).

First option - install it in calibre, and use the GUI to run it, you have the View Log button in the GUI to see any log output you have. For normal UI plugins, you can launch calibre with calibre-debug -g and have the logging printed to the console. This doesn't work with metadata plugins however.

Second option - take a look at any of my plugins like the B&N plugin. At the bottom of __init__.py, you will see a "if __name__ == '__main__'" section. This is to allow testing the plugin from a command line outside of calibre. You can see the command line to launch it from the plugin directory:

calibre-debug -e __init__.py

When you do this, you will get some log output to the console window, and the rest gets written to a file, the location of which is specified in the console output.

One very important note - executing plugin codes in this way will *only* load the local directory version of the file that you launched in that command line - in this case __init__.py. If your plugin has other files that need to be called (worker.py in the case of the B&N plugin), then they *must* be installed first in calibre by installing your plugin using the normal command line route.

And remember that any time you make a change to one of those supporting files, you must run the command line again to re-zip/add the plugin to calibre, before then running the command line above to execute your test code. Otherwise your code is going to be using the "old" version of those files that calibre knows about (not the ones in the local directory remember). You can drive yourself mental making changes and seeing them have no effect (I did until I figured this out!).

Having said all of the above, I know Kovid made some changes a month or two ago to support other ways of installing/testing plugins. It may be there is a quicker way of doing it. I'm too set in my ways with all my existing batch files etc I have "honed" over the years to break my habits just yet but he may have a better answer for you.

[kovidgoyal]

metadata download runs in a worker process (MD plugins often leak memory), that worker process does not log to console. It's log is made available via the view log button in the metadata download dialog.

You can also run your metadata plugin code from the command line with logging to a text file by putting all the code in a single __init__.py file and adding a __name__ == '__main__' section and running it with calibre-debug -e as kiwidude describes. This is the best way to develop a MD plugin.

@kiwidude: The new plugin handling code is simply

calibre-customize -b /path/to/dir/with/plugin/source/code

which automatically zips up and installs/updates the plugin into calibre. So for example, if your metadata download plugin has multiple files, you can do, (in the plugin's directory):

calibre-customize -b . && calibre-debug -e __init__.py

[kiwidude]

Thanks Kovid, I knew there was some new trickery and that fits in with what I thought.

It isn't something I personally will use purely because I have other files I store in my plugins folder that I don't want to be a part of the zip, and because I have a "common" utils file that is shared between plugins that is stored in a completely different folder. However for other developers who do have a completely self contained set this is a great feature.

[charlweed]

Thank you both!
This should be enough to start hacking