nordisk/znippy

znippy-plugin-python — crate card

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

• One-line pitch: Package handler that extracts Python wheel/sdist metadata (PEP 427/503/658) for the znippy metadata index.
• Does: extract_python_metadata(path, _data) parses the wheel filename (name/version/python_tag/abi_tag/platform_tag → WheelInfo) without opening the file (wheel.rs, parse_wheel_filename). For deeper resolution it scans inside the wheel ZIP for *.dist-info/METADATA (PEP 658) and RECORD via a hand-rolled central-directory walk with miniz_oxide inflate. native.rs (behind host-decompressors) exposes NativePythonPlugin implementing the plugin trait.
• Key deps: miniz_oxide (wheel ZIP inflate), optional lzip-parallel+rayon+znippy-common (native host plugin; sdist/xz handling).
• Shape: lib compiled as both cdylib and rlib (WASM), ~440 LOC: native.rs (160), wheel.rs (154), lib.rs (126).
• Observed role in the workspace: Registered in znippy-cli/handlers.rs as NativePythonPlugin; exercised by the integration and read-API tests. Same source, two compile targets (native + WASM).

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: