nordisk/holger

holger-znippy-conda-repository — crate card

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

• One-line pitch: znippy-archive-backed Conda channel — serves repodata.json + packages for conda/mamba.
• Does: CondaRepoZnippy implements RepositoryBackendTrait serving per-subdir repodata.json, plus .tar.bz2 (classic) and .conda (new) packages. Backed by a concrete ZnippyArchive it uses the typed conda view (as_conda): name/version/build/subdir come from index columns the plugin parsed from each package's info/index.json. R4 fix: repodata.json is a REAL index (packages map keyed by filename with {name, version, build, subdir, size, sha256}) built from authoritative coords, not the old {"packages":{}, "packages.conda":{}} stub. Synthesized index cached (immutable archive), guarding DoS amplification.
• Key deps: traits, znippy-common (typed conda view), anyhow.
• Shape: lib, single lib.rs. Shared znippy-backend pattern.
• Observed role in the workspace: Registered in server-lib as repository-znippy-conda. Per CLAUDE.md "real repodata.json".

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: