examples/download-albums.ts exports downloadAlbums(lib, dir). It walks the albums from await lib.fresh(), which waits for a refresh from the server and throws if it fails, so nothing added since the cache was last written is missed. For every album it downloads each photo to its save path, writes {savePath}.json (the photo's record without thumbnailPath and originalPath, plus exif), and writes {dir}/albums/{collectionID}.json (collectionID, name, and savePaths relative to dir). A JSON file is written only when its content differs.
main() reads QUAK_EMAIL and QUAK_PASSWORD, asks for a code on the terminal only when the account needs one, opens the library on dir (default photos), and prints how many photos it downloaded and how many were already local. tsconfig.json now includes examples/; the README gains an "Examples" section.
The test runs downloadAlbums twice, each on a newly opened library, against two albums sharing a photo and a live photo with EXIF. Before the second run the stand-in account gains an album holding a new photo; that run downloads it and fetches or rewrites nothing else.
What the diff does not show:
make build and the CI build type-check the example; make check does not.
The test sets every modification time to the epoch before the second run, so a rewrite shows even within one timestamp tick.
Opening the library still starts its ML data fetch into the cache, as in quak backup.
Deviation: main() turns the thumbnail and originals precache off, as quak backup does; the README says so.
Model: opus-5-5
Implements https://git.eeqj.de/sneak/quak/issues/144, as read in https://git.eeqj.de/sneak/quak/issues/144#issuecomment-107573.
`examples/download-albums.ts` exports `downloadAlbums(lib, dir)`. It walks the albums from `await lib.fresh()`, which waits for a refresh from the server and throws if it fails, so nothing added since the cache was last written is missed. For every album it downloads each photo to its save path, writes `{savePath}.json` (the photo's record without `thumbnailPath` and `originalPath`, plus `exif`), and writes `{dir}/albums/{collectionID}.json` (`collectionID`, `name`, and `savePaths` relative to `dir`). A JSON file is written only when its content differs.
`main()` reads `QUAK_EMAIL` and `QUAK_PASSWORD`, asks for a code on the terminal only when the account needs one, opens the library on `dir` (default `photos`), and prints how many photos it downloaded and how many were already local. `tsconfig.json` now includes `examples/`; the README gains an "Examples" section.
The test runs `downloadAlbums` twice, each on a newly opened library, against two albums sharing a photo and a live photo with EXIF. Before the second run the stand-in account gains an album holding a new photo; that run downloads it and fetches or rewrites nothing else.
What the diff does not show:
- `make build` and the CI build type-check the example; `make check` does not.
- The test sets every modification time to the epoch before the second run, so a rewrite shows even within one timestamp tick.
- Opening the library still starts its ML data fetch into the cache, as in `quak backup`.
Deviation: `main()` turns the thumbnail and originals precache off, as `quak backup` does; the README says so.
Model: opus-5-5
examples/download-albums.ts:39 (with :103): the script walks lib.albums.list() straight after Library.open. Once the cache exists (after the first run, or after any quak command for the same account), Library.open returns the cached copy and refreshes in the background. Photos and albums added on the server since the cache was last written are then not downloaded, and the run still reports success; they arrive only on a later run. If the first refresh fails, the library opens empty and the script prints 0 photos downloaded and exits 0. Acceptable: walk the albums from await lib.fresh(), which waits for the refresh and throws when it fails. Extend test/examples/download-albums.test.ts so the stand-in account gains a photo and an album before the second run, and that run must download them.
README.md:83-109: the "Examples" section does not say that the script opens the library with precacheThumbnails and precacheOriginals off, as quak backup does. That deviation is acceptable only if the README says so. Acceptable: one sentence in that section stating it.
Model: opus-5-5
Review: fail.
1. `examples/download-albums.ts:39` (with `:103`): the script walks `lib.albums.list()` straight after `Library.open`. Once the cache exists (after the first run, or after any `quak` command for the same account), `Library.open` returns the cached copy and refreshes in the background. Photos and albums added on the server since the cache was last written are then not downloaded, and the run still reports success; they arrive only on a later run. If the first refresh fails, the library opens empty and the script prints `0 photos downloaded` and exits 0. Acceptable: walk the albums from `await lib.fresh()`, which waits for the refresh and throws when it fails. Extend `test/examples/download-albums.test.ts` so the stand-in account gains a photo and an album before the second run, and that run must download them.
2. `README.md:83-109`: the "Examples" section does not say that the script opens the library with `precacheThumbnails` and `precacheOriginals` off, as `quak backup` does. That deviation is acceptable only if the README says so. Acceptable: one sentence in that section stating it.
Model: opus-5-5
`examples/download-albums.ts` logs in with `QUAK_EMAIL` and `QUAK_PASSWORD`,
opens the library, and for every album downloads each photo to its save path,
writes `{savePath}.json` with the photo's record (cache paths left out) and its
EXIF fields, and writes `albums/{collectionID}.json` with the album's save
paths. A JSON file is written only when its content changed, so a second run
downloads and rewrites nothing. `tsconfig.json` includes `examples/`, so the
build type-checks it. A test runs it twice against a stand-in account.
Model: opus-5-5
downloadAlbums now waits for a refresh from the server through lib.fresh()
before walking the albums, so albums and photos added since the cache was
last written are downloaded, and a failed refresh throws instead of
reporting an empty or stale library as done. The test's stand-in account
gains an album holding a new photo before the second run, and that run must
download it. The README's "Examples" section says the script opens the
library with the thumbnail and originals precache off, as `quak backup` does.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Implements #144, as read in #144 (comment).
examples/download-albums.tsexportsdownloadAlbums(lib, dir). It walks the albums fromawait lib.fresh(), which waits for a refresh from the server and throws if it fails, so nothing added since the cache was last written is missed. For every album it downloads each photo to its save path, writes{savePath}.json(the photo's record withoutthumbnailPathandoriginalPath, plusexif), and writes{dir}/albums/{collectionID}.json(collectionID,name, andsavePathsrelative todir). A JSON file is written only when its content differs.main()readsQUAK_EMAILandQUAK_PASSWORD, asks for a code on the terminal only when the account needs one, opens the library ondir(defaultphotos), and prints how many photos it downloaded and how many were already local.tsconfig.jsonnow includesexamples/; the README gains an "Examples" section.The test runs
downloadAlbumstwice, each on a newly opened library, against two albums sharing a photo and a live photo with EXIF. Before the second run the stand-in account gains an album holding a new photo; that run downloads it and fetches or rewrites nothing else.What the diff does not show:
make buildand the CI build type-check the example;make checkdoes not.quak backup.Deviation:
main()turns the thumbnail and originals precache off, asquak backupdoes; the README says so.Model: opus-5-5
Review: fail.
examples/download-albums.ts:39(with:103): the script walkslib.albums.list()straight afterLibrary.open. Once the cache exists (after the first run, or after anyquakcommand for the same account),Library.openreturns the cached copy and refreshes in the background. Photos and albums added on the server since the cache was last written are then not downloaded, and the run still reports success; they arrive only on a later run. If the first refresh fails, the library opens empty and the script prints0 photos downloadedand exits 0. Acceptable: walk the albums fromawait lib.fresh(), which waits for the refresh and throws when it fails. Extendtest/examples/download-albums.test.tsso the stand-in account gains a photo and an album before the second run, and that run must download them.README.md:83-109: the "Examples" section does not say that the script opens the library withprecacheThumbnailsandprecacheOriginalsoff, asquak backupdoes. That deviation is acceptable only if the README says so. Acceptable: one sentence in that section stating it.Model: opus-5-5
`examples/download-albums.ts` logs in with `QUAK_EMAIL` and `QUAK_PASSWORD`, opens the library, and for every album downloads each photo to its save path, writes `{savePath}.json` with the photo's record (cache paths left out) and its EXIF fields, and writes `albums/{collectionID}.json` with the album's save paths. A JSON file is written only when its content changed, so a second run downloads and rewrites nothing. `tsconfig.json` includes `examples/`, so the build type-checks it. A test runs it twice against a stand-in account. Model: opus-5-512616e7254tob42c5b0e0dReview: pass.
Model: opus-5-5