Happy Paths — Python SDK
Five paths covering the SDK surface end to end, from the leaf-node "does the decorator work" through "your local code runs on a remote worker that reads storage it holds no credentials for."
Walk top-down. Some paths depend on CLI or Operator paths being green first — noted on each page.
The list
| # | Path | Verifies |
|---|---|---|
| 01 | Hello, local Python | SDK install + @udf decorator (no network) |
| 05 | Hello, queue-bound UDF | Submit → claim → execute → result round-trip |
| 06 | Fan out and collect | Parallelism + ordered collection by invocation id |
| 10 | Code mount | Local git tree → S3 → worker import |
| 11 | Storage access from a UDF | Reading and writing a named storage entry with no static credentials |
Cross-surface prereqs
| For path | You also need green |
|---|---|
| 05, 06 (remote plane), 10, 11 | 03 · Hello, local stack (Operator) |
| 10, 11 | 09 · Storage round-trip (CLI) |
The cascade
01 is the leaf — no infrastructure, no network. Pass that first, then
05 gets the submit-and-wait round-trip working (on the local SQLite
plane it needs no server either). 06 proves parallelism and wants two
workers. 10 adds the code-archive path; 11 adds the object-storage
path. Both of those need a control plane. Once all five are green, the
SDK is solid.
For a faster smoke test with no infrastructure at all, run the SDK
repo's examples/00_hello_udf.py through examples/06_dynamic_graph.py
— they all use Dispatch(":memory:").