Command to extract task prerequisites

[hjoliver]

(Request from NIWA operations): it would be useful to be able to extract a task's prerequisites as a simple list of tasks rather than (as via cylc show now) a formatted string with nasty verbose task name munging to handle conditional triggers.

[hjoliver]

(this should include tasks in the runahead pool). (cylc show already does this from cylc-7)

[matthewrmshin]

I thought I knew what you meant, but I thought I would test it out with a simple example (t1 | t2) => t3.

cylc show SUITE t3 gives:

prerequisites (- => not satisfied):
  -     LABEL: t1_colon_succeed = t1.1 succeeded
  -     LABEL: t2_colon_succeed = t2.1 succeeded
  - CONDITION: (t1_colon_succeed|t2_colon_succeed)

It is interesting that we already have LABEL statements as legend to the formatted string with nasty verbose task name munging. I guess the obvious fix is to replace any strings in the CONDITION statement matching any of the LABEL values?

A slightly longer term fix is to re-factor the internal representation of the conditional triggers? E.g.:
Instead of using a string, can we use a simple data structure or class to represent the condition?

[matthewrmshin]

Related to #1346?

[hjoliver]

Yes and yes. I'll take a shot at the short term fix...

[oliver-sanders]

I created a branch whilst looking at #1346 which might satisfy the short term fix for this issue.

https://github.com/oliver-sanders/cylc/tree/1346.make-conditional-labels-more-user-friendly

Before

prerequisites (- => not satisfied):
  -     LABEL: a_colon_succeed = a.1 succeeded
  -     LABEL: b_colon_succeed = b.1 succeeded
  -     LABEL: c_colon_succeed = c.1 succeeded
  -     LABEL: d_colon_succeed = d.1 succeeded
  - CONDITION: a_colon_succeed&b_colon_succeed&(c_colon_succeed|d_colon_succeed)

After

prerequisites (- => not satisfied):
  - a.1 succeeded & b.1 succeeded & (c.1 succeeded | d.1 succeeded)

Otherwise we could do something like this (as suggested in #1346 (comment)):

prerequisites (- => not satisfied):
 -      A: a.1 succeeded
 -      B: b.1 succeeded
 -      C: c.1 succeeded
 -      D: d.1 succeeded
 - A & B & (C | D)

[hjoliver]

@oliver-sanders - thanks, another one I didn't get time to follow through on 😬 Your result looks good, but I wonder if we could have the second too as an option because it is probably easier to understand in the case of long family triggers etc.?

[hjoliver]

Actually you've solved #1346.

This issue arose from a request for something even simpler: a list of upstream tasks that the given task depends on, regardless of the form of the dependence. So:

a.1 b.1 c.1 d.1

(or perhaps with ':succeeded' etc. appended to each).

[oliver-sanders]

I wonder if we could have the second too as an option because it is probably easier to understand in the case of long family triggers etc.?

Long family triggers with datetime cycling will definitely use a lot of horizontal space so this is probably the way to go. Should this be optional or the default behaviour?

[hjoliver]

IMO it should be the default, because it is human-readable (without scrolling) even for long trigger expressions. But the single-line form could be an option. As could my "just the upstream task IDs" as above.

Regarding Matt's longer term fix, yeah the internal representation could be improved. The reason for the current for is it's a string that can be eval'd as a Python expression. But that's not ideal, and very verbose.