Compact home, detailed onboarding here
Start building with Retriever after install.
This page holds the longer onboarding path that no longer fits on the front door. Use it after the compact home page: keep install visible, choose a first run, then branch into runtime guides, debugging, architecture, or API material without mixing that flow with paper or research framing.
- Home stays brief
- Treat it like an abstract plus installation
- This page carries detail
- Onboarding, build path, and route selection live here
- Research stays separate
- Paper framing remains off this runtime-oriented surface
Keep the domain split stable while navigating: openretriever.org is the launch surface, openretriever-docs.pages.dev holds runtime docs, and retriever-space.pages.dev holds Golden examples.
Recommended path
Install, run, then choose depth deliberately
Install guide, tutorial index, and the first working demo route.
Start from the canonical runtime guide before touching deeper concepts.
Use debugging, execution, and architecture docs once the first run is live.
Jump into the API and handbook after the onboarding guides have oriented you.
Keep docs routes explicit
These are the key pages to keep open while evaluating fit
Pixi-first setup, optional pip or uv path, and troubleshooting notes.
A docs-first curriculum from flow fundamentals through release readiness.
Canonical pipeline authoring, validation, stepping, and backend execution.
Use Pipeline.step() for local, in-process debugging with real breakpoints.
Make the install decision obvious, then make the first working sequence obvious too.
New users should not need to infer the sequence. On the Start page, the intended path stays explicit: pick the recommended install lane, get a concrete proof that the runtime is alive, then keep the runtime and debugging docs close while you evaluate fit or start integrating a real graph.
Start with Pixi for the cleanest setup, then keep the documented pip or uv fallback nearby if your environment needs it.
Use the tutorial index to launch a real example quickly instead of reverse-engineering the repository layout.
Once the first run works, the next reads should explain stepping, synchronization, execution, and system shape.
This page carries the longer onboarding, first-run, and build-routing detail so the homepage can stay compact. The runtime still shares one integrated product and docs surface.
Uses the repo’s default environment path and gets you to demo-webcam-detection with the least setup friction.
The install guide documents the plain Python environment path when you need to stay inside an existing setup.
Go from install straight into a real example, then keep the runtime and debugging guides open while evaluating fit.
Install and first run
Commands and confidence checks people actually need first
# recommended setup
curl -fsSL https://pixi.sh/install.sh | bash
# first proof the runtime is alive
pixi run demo-webcam-detection
# optional local confidence check before deeper integration
pixi run python -m pytest tests -qThe fallback path is documented in the same install guide instead of being hidden behind repository archaeology.
Tutorials first, then the runtime guide, then debugging or architecture depending on whether you are validating behavior or integrating a larger system.
Builder sequence
- Install with Pixi or use the documented plain Python fallback.
- Run one tutorial-backed demo to prove the environment and repo layout make sense locally.
- Keep the runtime and debugging guides open while shaping your own flow graph.
Why this feels credible fast
Keep these routes close
A start page that tells new users exactly where to go next.
The homepage should not compete with the docs. This page can do the longer routing work instead: send people into the right page fast, preserve the install-to-learning sequence, and make the docs feel like a coherent product surface rather than a loose directory.
Install guide, tutorial index, and the first working demo route.
Start from the canonical runtime guide before touching deeper concepts.
Use debugging, execution, and architecture docs once the first run is live.
Jump into the API and handbook after the onboarding guides have oriented you.
Installation
Recommended Pixi setup, alternatives for pip or uv, and the environment details people usually need first.
Tutorial tracks
A docs-led path from mental model to debugging, release readiness, and operations interfaces.
Runtime guide
The canonical explanation of authoring, validation, stepping, and backend execution.
Debugging guide
Pipeline stepping, replay, and investigation workflows for local iteration before backend complexity shows up.
Architecture
A higher-level map of how the runtime pieces fit together once you are past the first install.
API reference
Reference material for exact interfaces after the install path and guides have oriented you.
Default docs route
- Install with the recommended environment path.
- Run tutorials for an immediate working surface.
- Understand the runtime through canonical guides.
- Go deeper with architecture, debugging, and API reference.
This route keeps the public map explicit: openretriever.org for launch, openretriever-docs.pages.dev for runtime docs, and retriever-space.pages.dev for Golden examples until custom domains are active.
Core guides kept visible
Open handbookThe Start page should still prove why the runtime is worth installing.
Product conviction matters after the install path. Retriever is useful because it keeps pipeline structure explicit, supports local debugging early, and lets teams keep the authored graph while backend requirements grow from local multiprocessing to dora-backed execution.
from dataclasses import dataclass
from retriever.flow import Flow, Pipeline, Rate, Latest, flow_io
@flow_io
@dataclass
class CameraOut:
image: bytes
class Camera(Flow[None, CameraOut]):
def run(self, _): # type: ignore[override]
...
pipe = Pipeline("quickstart")
camera = Camera() @ Rate(hz=30)
pipe.connect(camera, detector, sync=Latest())
pipe.step(dt=0.1) # local debugging
pipe.run(backend="multiprocessing")What you can verify immediately
- The repo exposes a Pixi-first install path and a documented plain Python fallback.
-
The docs explicitly teach
Pipeline.step()before heavier backend execution. - Runtime, debugging, architecture, handbook, and API routes all stay visible from this surface.
Scope of this site
This mirror website is the install and documentation surface for the runtime. Research narratives, paper framing, and evaluation storytelling remain intentionally separate so the first-run experience stays operational and the domain split stays clear.
Keep openretriever.org as the launch surface, route runtime detail to
openretriever-docs.pages.dev, and use retriever-space.pages.dev for Golden examples.
Runtime advantages
Use Python types and explicit contracts to make flow boundaries legible before runtime bugs become distributed bugs.
Inspect state changes in-process with Pipeline.step() before switching to a heavier execution backend.
Keep the same authored graph while moving from local multiprocessing to dora-backed execution.
The public site is optimized for installation and onboarding, while research and paper storytelling stay elsewhere.
Trust cues kept visible
The public repo, issues, and discussions are one click away for source-level inspection.
Adoption and evaluation stay low-friction because the runtime is published under Apache 2.0.
The docs explicitly center Pipeline.step() for in-process breakpoints and replay-friendly debugging.
Author once, debug locally with multiprocessing, then move into dora-backed execution as needed.
Choose the next route
Go back to installation and use the recommended environment route.
Read the canonical guide for authoring, validation, stepping, and backend execution.
Use the debugging guide to inspect the graph before backend complexity enters the loop.