Quote:
Originally Posted by kovidgoyal
You're welcome, though why not just use the builtin calibredb command line tool with a script?
|
This question is the right one, and it's the question the project grew out of. It started in March as a single stdlib script for exporting my virtual libraries to text files, because I kept writing small parsers around calibredb's output to get machine-readable answers. The first README line even said "without calibredb". The zero-dependency library underneath it (cquarry) came out of that same work in August.
What ended up mattering:
- It's a library, not a subprocess. My tools import it and get structured rows back in-process instead of parsing calibredb's text output, and it's pure stdlib so it works wherever Python is installed.
- The read side works while Calibre is open. It opens the database in read-only mode, and if Calibre holds the lock it falls back to a snapshot copy. Scripting against calibredb locally means waiting for Calibre to close, since it shares the GUI's single-instance lock.
- The pile of scripts became reporting modes: series gap detection, audits (untagged/unrated/coverless, duplicates, database-vs-folder mismatches), stats scoped to a virtual library, and machine-readable exports.
And to be fair about where calibredb wins, it isn't close: adding books with the metadata plugins, the embed/backup/restore/clone verbs, content-server access to remote libraries, catalog generation to EPUB or MOBI, and schema changes tracked upstream automatically instead of by me. My run flush verb literally shells out to calibredb embed_metadata, because it is the right tool for that job.
If any of this is already in calibredb and I missed it, I'd genuinely like to know. I'd rather lean on the builtin where it fits.