Files
dora-image-view/dataflow.yml
cristhian c1dba8998d build with uv rather than pip
The build command was `pip install .`, which is what the dora docs use because
`--uv` rewrites it. Spelling it `uv pip install .` means the dataflow never
installs through pip at all, whether or not `--uv` was passed. The cost is that
a node then needs a virtualenv to install into, so dataflows must be run with
`--uv`; AGENTS.md says so.

Note that the PR #3 branch still carries `pip install .`; landing this branch
on top of it is what corrects that.
2026-09-15 06:09:33 -03:00

67 lines
2.7 KiB
YAML

# The end-to-end test: a synthetic source feeding the viewer. Everything it
# needs is in this checkout -- no camera, no detector, no network -- which is
# what lets CI run it rather than only validate it.
#
# It lives at the repository root rather than beside tests/source.py because a
# node's working directory is the directory of the dataflow file, and both
# nodes build with `uv pip install .`, which needs pyproject.toml in that
# directory.
#
# Both nodes are built from the checkout with `path:` + `build:`, which is what
# lets `dora validate` pick up the typed contract in dora-node.yml. A consumer
# wires the viewer from a tag instead -- see README.md.
#
# Run it with `--uv` so every node gets its own managed environment.
# strict_types makes a type warning a non-zero exit. It also means a *typed*
# manifest input must be wired below: `dora validate --strict` warns
# `input_types key "..." not found in inputs list` for any it leaves unwired, so
# a new typed input on the node has to be driven from tests/source.py with a
# matching entry in `output_types` here, or left untyped.
strict_types: true
nodes:
- id: source
# Run through the interpreter rather than as `path: tests/source.py`.
#
# A dora-node.yml describes exactly one node and is what gets published
# (`dora hub publish` expects it beside pyproject.toml), and this
# repository ships one node: dora-image-view. The example source is a test
# fixture, not a node anyone installs, so it gets no manifest.
#
# That has a mechanical consequence. `dora validate` matches a manifest to
# a `path:` node by entrypoint, so a path node here would be tried against
# the root manifest, would not match its `dora-image-view` entrypoint, and
# would warn -- which strict_types turns into a failure. Going through the
# interpreter leaves nothing for it to match, and `output_types` below is
# the documented way to type an output without one.
path: python
args: tests/source.py
# The source needs dora-rs, numpy and pyarrow; installing the project gives
# it exactly the versions pinned in uv.lock.
build: uv pip install .
inputs:
tick: dora/timer/millis/33
outputs:
- image
- depth
- camera_info
- bbox
- text
# bbox is deliberately absent: it is untyped on the viewer's side too,
# because senders disagree on 32- vs 64-bit numeric fields.
output_types:
image: std/media/v1/Image
text: std/core/v1/String
depth: std/media/v1/Image
camera_info: std/core/v1/Float32
- id: view
path: dora-image-view
build: uv pip install .
inputs:
image: source/image
depth: source/depth
camera_info: source/camera_info
bbox: source/bbox
text: source/text