DAG Paths

[Leahh02]

I made multiple versions of the DAGs without overriding old versions. I also added an argument to specify where to save the DAGs to. I updated the documentation for this. I wrote this on my personal computer and still need to test it on Darwin.

[Leahh02]

The DAGs are being saved in a DAG directory within the directory they specify right now. So running beeflow dag $SHORT_ID $WORKDIR will save the Dags in a directory $SHORT_ID_dags and that directory is in the $WORKDIR.

If someone doesn't want to make the dags directory they can use the --no-dag-dir and the dags will just be saved in the directory they specify.

You can now make multiple versions of the DAGs. The current one is $SHORT_ID.png, and then the other ones are $SHORT_ID_v1.png, $SHORT_ID_v2.png ... where v1 is the oldest

I'm saving the final dag to the workflow directory which then gets saved to the archive directory.

I updated documentation for these changes.

I haven't changed how things are named yet, which was something in issue 921 and is similar to these changes.

[Leahh02]

I can change the names of the dags directory and the actual dags themselves to whatever people think is best. I.e. I can change the $SHORT_ID_dags directory and the $SHORT_ID_dags

[pagrubel]

You can now make multiple versions of the DAGs. The current one is $SHORT_ID.png, and then the other ones are $SHORT_ID_v1.png, $SHORT_ID_v2.png ... where v1 is the oldest

@Leahh02 I like your explanation here and think something like it should be added to the documentation for clarification such as:

"The most recent version is $SHORT_ID.png and the others are $SHORT_ID_v1.png, $SHORT_ID_v2.png ... where v1 is the oldest."

[pagrubel]

@Leahh02 Would it be useful to have the graphmls in the workflow archive? You mentioned earlier they might be useful for debugging.

This looks very good and flexible for the user. If you can fix the tests and make the small documentation change I think we should merge this.

[pagrubel]

This looks good. I added a comment to the main issue about having a Dockerfile for the neo4j container, so it can be updated in one place. This can be done when the beeflow core pull-deps is fixed though.