Repository navigation
v0.9.0
Not published to PyPI. Use v0.9.1. A Windows-only test failure stopped the publish job. v0.9.1 ships this same code, with that test fixed.
find, audit, and create's duplicate check are now fast on repeat calls, and their answers are just as complete.
What was slow. These commands walk every top-level item, and the cost was transfer, not request count. Item JSON is about 0.5 MB per 100 items; requests were already 100 per page and gzipped, and fetching pages in parallel measured slower. On a slow link to api.zotero.org, a few hundred items took 10–20 s per call, and agent loops of find --any <author> could hit tool timeouts.
What changed.
- zotkit now keeps the last listing in a local cache. Before each use it fetches the server's
format=versionsmap for that listing, which is a tiny but complete key → version index. Only items whose version moved are re-downloaded, and items the map no longer names are dropped. - There is no TTL and no stale mode, so a cached zero hit from
findis as trustworthy as a fresh one. If the versions map can't be fetched, or comes back incomplete, the command fails instead of answering from the old copy. - Measured on a library of a few hundred items: repeat
find13.7 s → 2.4 s, repeataudit11.1 s → 2.5 s. Cached and uncached outputs are byte-identical. - The first call on a machine still downloads everything.
New on disk. The cache lives in ~/.cache/zotkit ($XDG_CACHE_HOME/zotkit if set; %LOCALAPPDATA%\zotkit on Windows), one directory per library. It holds your items' metadata as the Web API returns it, abstracts included. Set ZOTKIT_CACHE=0 to disable it.
Design record: ADR-0004. 165 offline tests; CI (ubuntu + windows × 3.11/3.13) gates the publish.