Discussion: Default working directories

[phil-opp]

There were some reports that our current working directory selection is too complicated and unintuitive. Let's try to find better defaults in this discussion.

Issue Report

Originally posted by @theol0403 in #1066 (comment):

I ran into this issue today when trying to set up distributed nodes.

Using just a local python node works fine:

  - id: keyboard_controller
    build: pip install -e keyboard_controller
    path: keyboard_controller/src/main.py
    inputs:
      tick: dora/timer/millis/100

  - id: rust_node
    build: cargo build -p rust_node
    path: target/debug/rust_node
    inputs:
      tick: dora/timer/millis/100

Then, dora build and dora start work as expected and start the python and rust nodes locally.

However, making just the rust node distributed:

  - id: rust_node
    _unstable_deploy:
      machine: other
    path: dynamic
    inputs:
      tick: dora/timer/millis/100

Causes keyboard_controller on the LOCAL daemon to fail.

keyboard_controller on default daemon : stdout    /opt/homebrew/Cellar/python@3.12/3.12.11/Frameworks/Python.framework/Versions/3.12/Resources/Python.app/Contents/MacOS/Python: can't open file '/Users/theol/Documents/github/rust-ethercat/_work/01981518-3271-7b98-9fcc-97fd5d61297c/keyboard_controller/src/main.py': [Errno 2] No such file or directory
keyboard_controller on default daemon : stdout    
keyboard_controller on default daemon : stdout    
keyboard_controller on default daemon : ERROR  daemon    exited with code 2 with stderr output:
---------------------------------------------------------------------------------
/opt/homebrew/Cellar/python@3.12/3.12.11/Frameworks/Python.framework/Versions/3.12/Resources/Python.app/Contents/MacOS/Python: can't open file '/Users/theol/Documents/github/rust-ethercat/_work/01981518-3271-7b98-9fcc-97fd5d61297c/keyboard_controller/src/main.py': [Errno 2] No such file or directory
---------------------------------------------------------------------------------

Then, changing the python node to:

  - id: keyboard_controller
    build: pip install -e ../../keyboard_controller
    path: ../../keyboard_controller/src/main.py
    inputs:
      tick: dora/timer/millis/100

solves the problem. But, I think this is very unintuitive and was very difficult to troubleshoot. Now, when commenting out the distributed rust node, the python node fails because the paths are wrong!

[phil-opp]

Let me summarize how we set the working directory currently:

• Use the path specified in _unstable_deploy.working_dir if set. Else:
• For dora run, use the parent directory of the dataflow file as working directory.
• For dora start, use a _work/<session_id> subdirectory of the directory where the dora daemon was started.
  • Where <session_id> is a unique identifier for the dataflow.yml that is started
  • We choose this subdirectory to avoid conflicts with other dataflows that are running on the same daemon
  • Exception: If no _unstable_deploy keys are specified in the dataflow and if the CLI and daemon are running on the same machine, we use the parent directory of the dataflow file as working directory (like for dora run)
• For nodes with git keys, we clone the repo into a git/<repo_domain>/<repo_path> subfolder of the working directory
  • Then we set the working directory of the node to this clone
• For dora build, we choose the same working directories as for dora start.
  • For dora build --local, we choose the same working directories as dora run

I agree that this is quite complex and that it would be nice to simplify this.

[phil-opp]

Proposal from @theol0403 :

It would be good if the nodes were spawned in the working directory of their daemons.

Could you clarify in which of the above cases this should apply in your opinion? Just for distributed dataflows? Or also for local dataflows, instead of using the parent directory of the dataflow yaml file?

What about nodes with git sources? We probably don't want to clone directly into the working directory and overwrite everything there, right? So I assume that we still want to clone into subfolder. Do we want to keep that subfolder as working dir for the build/run/start commands or would you prefer to use the working dir of the daemon instead (i.e. not use the clone dir as working dir)?