nordisk/holger

holger-rust-znippy-repository — crate card

Reverse-engineered (from source — verify, don't trust the name)

• One-line pitch: znippy-archive-backed Rust/cargo crate repository — serves crates + a sparse index directly from a .znippy via random-access extraction.
• Does: RustRepoZnippy implements RepositoryBackendTrait. When backed by a concrete ZnippyArchive it uses the typed rust view (ZnippyArchive::as_rust) so crate coords come from the index columns the cargo plugin extracted, not from parsing {name}-{version}.crate filenames. Advertises a configurable base_url in the sparse index config.json dl field. Has a dev-mode writable path: put appends a crate into an on-disk .znippy (creating then growing it), reads re-open the archive. A generic with_reader fallback exists for non-archive readers.
• Key deps: traits, znippy-common (ZnippyArchive/ZnippyReader, typed views), anyhow.
• Shape: lib, single lib.rs (one of the larger/most-referenced backends — the canonical "read at least one in full" example).
• Observed role in the workspace: Registered in server-lib as repository-znippy-rust; also used directly by bench-scenarios, agent-cli tests, and holger-server-ui demo mode. This is the reference implementation the other znippy-* backends follow.

Fill in (one line each — only the human knows these)

• Primary consumer(s):
• Why it exists (vs the obvious alternative):
• Hard constraint (airgap / no-C-deps / no-FFI / pure-Rust / etc.):
• Release cadence & independence (rides a parent? own repo someday?):
• Status (production / prototype / experimental / stubbed):
• Must-NOT-change invariant:
• Biggest known gap or TODO:
• Anything a newcomer would get wrong about it: