change to tagging instead of pseudotasks?

[deanmalmgren]

Adding pseudotasks (#26) is a really nice feature for grouping tasks. One thing that @gabegaster and I realized during our code review is that it also adds a significant amount of complexity to the underlying code. One proposed way of simplifying things while still enabling this functionality is by having tags that you can place on particular tasks like this:

---
creates: a/figure
depends: another/file
command: run something {{depends}} > {{creates}}
tags:
  - figures

---
creates: another/figure
depends: another/file2
command: run something {{depends}} > {{creates}}
tags:
  - figures

Then you can run something like workflow run figures from the command line to effectively run anything with the figures tag. What do you think about this, @laurieskelly?

[laurieskelly]

It sounds good, if I understand it correctly!

[deanmalmgren]

Maybe we could also support something like this to make the notation more compact for situations in which you only have one tag:

---
creates: a/figure
depends: another/file
command: run something {{depends}} > {{creates}}
tags: figures
---
creates: another/figure
depends: another/file2
command: run something {{depends}} > {{creates}}
tags: figures

[gabegaster]

Point of clarification: were we thinking "tags" feature is mainly to be used as in workflow run figures? If that's the case then what about using the current notation like this:

---
creates: figures
depends:
    - a/figure
    - another/figure
command: touch figures

And then run workflow run figures

[deanmalmgren]

@gabegaster noting this for posterity, but as we discussed this is slightly undesirable because then it makes it difficult to build on the figures pseudotask.

@bjlange had another idea which was to have a separate file, perhaps a workflow-batches.yaml that specifies arbitrary groupings of tasks, perhaps like this:

figures:
  - a/figure
  - another/figure
tables:
  - a/table
  - another/table

In this setup, the keys would be the thing you could specify on the command line (e.g., workflow run figures) and the values would refer to the creates of tasks that are specified in the workflow.yaml.

[deanmalmgren]

got rid of pseudotasks in d4434ee, which is the last foreseeable backwards incompatible change before releasing v1.0.0

also, one possibility for the batches.yaml concept would be to put those in the .flo/ directory.