examples

Examples

Each folder is a self-contained Rust crate (the task, which is all that runs in the container) plus a small task.py that declares it to Flyte.

Example	Shows
hello-trace	The basics: sequential traced steps, structs between them, and calling the task from a Python workflow (workflow.py).
concurrent-traces	Many traced steps in flight at once — try_join_all over traced fns, each recorded and replayed independently, folded under a flyte::group.
retry-replay	Why traces exist: an expensive step is recorded, the task fails, and the retry replays the step instead of re-running it.
human-approval	Pausing for a person: two approvals are raised up front with flyte::condition, then collected. Needs a backend, and someone to answer.
reusable	Warm containers: a pool of replicas serves many actions instead of a pod per action. One extra dependency (union-reuse), one changed attribute, and reuse= on the Python side.
custom-image	Bringing your own Dockerfile instead of declarative layers — a system package in the runtime image, and a multi-stage build. Needs local docker.

Running any of them

The launcher comes from PyPI; the worker is built from this workspace.

pip install flyteplugins-rs

cargo test -p <example>          # dev loop: runs the task in-process, no backend

cargo build -p <example>         # the launcher reads the interface from the binary
cd examples/<example>
flyte run task.py <task-name> --<input> <value>

The task names and inputs come from the Rust signatures — ask the binary:

cargo run -p <example> -- describe-interface

Files in an example

File	What it is
src/main.rs	The task. #[flyte::main] makes the crate the worker entrypoint — or #[union_reuse::main], which additionally lets the binary serve a pool of actions.
Cargo.toml	A normal crate manifest depending on flyte = "0.1" from crates.io.
task.py	Declares the task to Flyte: reads the interface from the binary and builds the worker image. A handful of lines via flyteplugins-rs.
_generated_interface.py	Written by the launcher from describe-interface. Safe to delete — any launch with a built binary writes it back. Committed because a container has no cargo build to read the interface from.
.dockerignore	Keeps target/, Python and docs out of the worker image's build context — and out of the image tag, so launcher edits do not trigger rebuilds.
Dockerfile	Only in custom-image. The default is declarative layers, which the remote builder can compile without docker.

task.py imports the released flyteplugins-rs, exactly as your own project would. To run the examples against this checkout's launcher instead — when changing the launcher itself — use scripts/dev-setup.sh.

Each example is exactly what a user would write: flyte = "0.1" from crates.io, and a task.py with nothing repo-specific in it. A [patch.crates-io] in the root manifest redirects flyte to crates/flyte for in-workspace builds, so cargo test -p <example> still exercises the working tree — while the example directory on its own builds against the release, which is what the worker image does.