cristhian
92abe8a446
A dora-node.yml describes exactly one node and is the unit `dora hub publish` operates on, which expects it beside pyproject.toml. This repository ships one node, so it should carry one manifest. examples/dora-node.yml described a test fixture that nobody installs and that has no package of its own -- a manifest for something that is not a node. The source's outputs are now annotated with `output_types:` in the dataflow, which is the documented way to type an output without a manifest: "only annotated outputs are type-checked". It runs as `path: python` + `args:` because `dora validate` matches a manifest to a `path:` node by entrypoint, so a path node would be tried against the root manifest, fail to match `dora-image-view`, and warn -- fatal under strict_types. Through the interpreter there is nothing to match. The type gate is unchanged in strength: the viewer's contract is still injected and compared against the source's annotations, and a deliberate Float32 -> String swap still fails validate. The cost is that the fixture no longer gets a managed venv of its own and runs against the project environment. That applies to the fixture only; the shipped node still uses path: + build:, which is what a consumer exercises. This supersedes the approach in "fix strict-type validation by giving the example source a manifest" and the doc commit that cited the manifest-next-to-a-path-node rule as justification.
57 lines
2.2 KiB
YAML
57 lines
2.2 KiB
YAML
# The repository's own example, and its end-to-end test: a synthetic source
|
|
# feeding the viewer. Everything it needs is in this checkout -- no camera, no
|
|
# detector, no network -- so it is also what CI runs.
|
|
#
|
|
# 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: true
|
|
|
|
nodes:
|
|
- id: source
|
|
# Run through the interpreter rather than as `path: examples/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: examples/source.py
|
|
# The source needs dora-rs, numpy and pyarrow; installing the project gives
|
|
# it exactly the versions pinned in uv.lock.
|
|
build: 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/core/v1/UInt8
|
|
text: std/core/v1/String
|
|
depth: std/core/v1/Float32
|
|
camera_info: std/core/v1/Float32
|
|
|
|
- id: view
|
|
path: dora-image-view
|
|
build: pip install .
|
|
inputs:
|
|
image: source/image
|
|
depth: source/depth
|
|
camera_info: source/camera_info
|
|
bbox: source/bbox
|
|
text: source/text
|