The dataflow descriptor format still changes often, which led to parse errors. By doing the parsing lazily, this should only affect users of the `dataflow_descriptor` function from now on.
The coordinator now sends an immediate `DataflowStartTriggered` reply when receiving a `DataflowStart` command. This enables the CLI to directly attach to the dataflow and observe the build output.
To wait until the build/spawning is done, this commit introduces a new `WaitForSpawn` command, to which the coordinator replies with a `DataflowSpawned` message once the node has been started. We use this command for the `dora build` command.
Instead of running all the build commands directly, run them on their intended target machines through the coordinator.
This commit is a breaking change because a coordinator connection is now required for `dora build`.
This allows using up and start with uv:
## How to use:
```bash
cd examples/python-dataflow
dora up
dora start dataflow.yaml --uv
```
Fixes: https://github.com/dora-rs/dora/issues/780
This would help the CI as well
We use `/` as separator for input mappings in dataflow YAML files (e.g. input: `node/output_id`).
We do support `/` characters in output IDs for runtime nodes. If we allowed `/` characters in node IDs too, splitting a `a/b/c` mapping would no longer be possible (could be node `a` with output `b/c` or node `a/b` with output `c`). Therefore we explicitly error on node IDs containing `/` characters in this commit.
Send an exit message from the daemon to the coordinator on exit. This enables the coordinator to disconnect the daemon properly instead of waiting for a missed heartbeat signal.
The previous machine ID is still used, but optional. Users don't need to ensure that the chosen machine IDs are unique anymore because they are augmented with a UUID.
Make `dora-message` a dependency of `dora-core`, instead of the other way around. This way, we can continue to freely bump the version of `dora-core` with the other workspace crates, without introducing errors such as #708.