Example notebooks¶
Four marimo notebooks, easiest first. They are ordinary Python files, so they run as notebooks or as scripts, and they are executed on every docs build — if the API drifts from what they claim, the build fails rather than the page misleading you.
| Notebook | What it shows | |
|---|---|---|
| 1 | What a dataset knows | Dimensions, and the provenance of each one |
| 2 | An error before compute | A naming mismatch caught with nothing executed |
| 3 | A graph that has not run | Per-sample fan-out, and every error in one pass |
| 4 | Resistance, and why the rules are hashed | Vendored algorithms, and content hashing over version labels |
Running them¶
Or without marimo at all, since a marimo notebook is importable Python:
The first three need no data and no aligner — they use the tiny fixtures committed with the test suite, so they work on a fresh clone. The fourth runs the real interpretation if the HIV-1 demo data is present, and explains itself if it is not:
Why they are not interactive on this page¶
marimo can export a notebook that runs in the browser, through Pyodide. Ligase cannot use that: it is a compiled Rust extension, and there is no emscripten wheel for it — the published wheels are manylinux, macOS and Windows. Building one would mean PyO3 and a bundled SQLite compiled for emscripten, which is not a realistic target.
So these are rendered from real runs and meant to be downloaded and run locally, where the engine actually works. The honest version of "interactive docs" for a native extension is a notebook you can run, not an iframe that cannot import the thing it documents.
The full pipeline¶
The notebooks are deliberately small. For the reference pipeline end to end —
reads, alignment, variant calls, resistance — see
examples/hiv-resistance/pipeline.py
and running a pipeline.