[chaley]

Originally Posted by kiwidude

So getting the user to write code that inherits from a base class and overrides a function that is passed a populated Metadata object for the current row seems sensible. On that object the user can get/set as they please all the standard metadata fields and identifiers.

Setting a field in a Metadata object has no effect. You would need to call set_metadata.

What I don't believe they can get access to (Charles will correct me if wrong!) is the custom column fields, which are on the db object.

The Metadata object has all the metadata in it, including custom columns and user categories.

So I could also pass in a db object (which would give users more flexibility by also letting them do things like scrape covers).

The metadata object also can have the cover, if get_metadata is called with get_cover=True.

I am not sure whether passing a db handle is a good idea or not. If you pass it, you are giving away the keys to the city. If you don't, then there are some things like plugin custom data that the subclass would be unable to get.

EDIT: A potential technical challenge - is it possible to write a script that inherits from a class that exists only in a Calibre plugin zip file? Or would it require the base class to sit in the Calibre codebase, which could rather scupper the whole idea without Kovid's support.

It works both with the 'with self: import foo' scheme and with the zipimport scheme. As usual, the problem with the 'with xxx' scheme will be with name collisions. It would not be a good idea to have multiple plugins containing different versions of your base class all having the same name. For that reason I suggest that you use the zipimport technique, which will eliminate that problem.