Philipp Oppermann

Do we want to proceed with this approach? Personally, I think this is a considerable improvement because it changes the previous `Command` builder code to something that resembles normal shell...

@haixuanTao I get a `ModuleNotFoundError: No module named 'dora'` error again with the new `python-operator-dataflow` example. The `venv` is created before `dora up`, so it doesn't seem like the same...

We decided to wait a bit with this PR until https://github.com/dora-rs/dora/pull/551 is ready. We hope that we can create a proper integration test framework then instead of using the example...

> [ ] Make hard-coded `localhost` address configurable in the daemon and the coordinator Which hardcoded addresses do you mean? This should be already configurable by passing a `--coordinator-addr` argument...

Ah yes, we should use `0.0.0.0` in the coordinator to listen for incoming connections on all interfaces. For the `daemon`, the `127.0.0.1` should be fine since only local nodes should...

Ah yes, then we should listen on 0.0.0.0 in the deamon as well.

As far as I know, `0.0.0.0` acts as a kind of wildcard when listening. So it should listen for incoming connections on all available interfaces.

Ah, that makes sense, thanks for clarifying! I agree that making this configurable is a good idea then.

Yes, thanks a lot for all your work on this! The correct solution for the CLI would be to add a `coordinator_addr` argument to the `connect_to_coordinator` function. We would also...

I opened an issue with the next required steps for distributed dataflows: https://github.com/dora-rs/dora/issues/535. Discussion and pull requests are welcome!