Final task intervention command set about cylc-flow HOT 13 CLOSED

And if we keep remove as a separate command, we might need to resurrect spawn as well (remove/spawn vs set --forget/--recall) - currently those two operations are exact opposites, although they become less exactly opposite after the remove extension work.

from cylc-flow.

A) I vote no - I can't really see the justification just because they are related commands; I think there would be a needless degradation of user experience

from cylc-flow.

A) I vote no - I can't really see the justification just because they are related commands; I think there would be a needless degradation of user experience

OK highly unlikely we'll do A; but I think the primary reason is historical baggage.

Not sure how this:

cylc hold + cylc release

vs this:

cylc hold + cylc hold --release (i.e. one command for hold/resume function)

would be a degradation in user experience either way.

Arguably having a large number of commands makes for worse UX.

(After all, we are adding "set prerequisites" functionality into the "set outputs" command, to make a single command "cylc set"!)

from cylc-flow.

I'm not sure about "baggage". It seems logical that two operations that are opposite would have separate commands. It wouldn't make sense for pip uninstall to become pip install --uninstall for example.

from cylc-flow.

Fair point, but the command name matters and can be chosen appropriately. The grouping of functionality is the main thing). pip could conceivably have gone with something like pip manage --install / --uninstall .

from cylc-flow.

Need to read through this with more time, but I'm leaning, no & no.

Note that remove and set do very different things post proposal:

• Set, sets outputs and prerequisites for a task.
• Remove, removes flow numbers from a task.

Remove is not the opposite of set, it can't unset outputs, only flows.

from cylc-flow.

OK I think we're all happy to take A off the table (including me, I just felt it was worth considering whether the command set we've ended up with rather organically, could be better, in light of B which was my first concern given current work).

Note that remove and set do very different things post proposal:
Set, sets outputs and prerequisites for a task.

Unfortunately that isn't entirely true. It also (via --prerequisite=all) spawns tasks with no prerequisites into the active window without triggering them.

That functionality is the odd man out in cylc set . And, it happens to affect the same task property (presence in the active pool) that cylc remove does, hence this discussion.

Note the extended remove still does that, it doesn't only remove flow numbers. The most common use case for remove will still be to "forget" incomplete tasks that belong to only one flow and will thus be removed/forgotten from the active window.

Remove is not the opposite of set, it can't unset outputs, only flows.

Agreed, pretty sure I didn't say it was the opposite. [Looking back, was talking about spawn and remove]

from cylc-flow.

The (extremely) minimal fix for B would be to create a new set option with a more appropriate name, to handle the required manual spawning of parentless tasks. Because users are never gonna guess they need cylc set --prerequisites=all for that.

But then it does become more obvious that cylc set does more than just set prerequisites and outputs. And the fact is, the extra bit is closely related to what cylc remove does. Hence this whole can of worms 🤣

from cylc-flow.

cylc set --forget - drop a task from n=0 even if it is incomplete (c.f. "remove")

We did think of this at our end but came to the decision that set and forget (now renamed remove) were too different to be combined in this way. E.G. Consider the length and lack of commonality between the --help of the two commands.

cylc set --recall - bring a task into n=0 without triggering it

So --recall as an alternative to --pre=all? Note this is a rare use case which I expect will be almost entirely wiped out by #5416.

from cylc-flow.

Consider the length and lack of commonality between the --help of the two commands.

Yes I agree with that. I'm OK with leaving remove as a separate command on that basis. It has become a much bigger command, post proposal.

And I have just realized how to make the set --pre=all option more palatable (next...)

from cylc-flow.

The root of my problem with cylc set --pre=all is that I have been aiming for equivalence with cylc trigger, as per the proposal. Which says:

--pre=all: Set all prerequisites to satisfied. Equivalent to trigger.

Triggering a task runs it now, regardless of unsatisfied xtriggers. So we get:

1. Task foo has xtriggers and prerequisites:

   • cylc set --pre=all foo, spawns foo, sets all prerequisites, and triggers it

2. Task bar has xtriggers and no prerequisites, but we need to start checking its xtriggers

   • cylc set --pre=all bar spawns bar, and does not trigger it

What's being bugging me about 2. is:

• ?? why should anyone expect to have to use "set prerequisites" on a task that has no prerequisites?
• ?? why the triggering difference (well, I know why, but it looks like a bodge)

But it looks much better if we ditch the trigger equivalence and change the command description slightly:

--pre=xxx: spawn the task into the active window, and satisfy prerequisite xxx
--pre=all: spawn the task into the active window, and satisfy all prerequisites that it has (which includes none)

i.e. cylc set --pre brings tasks (all tasks equally) into the active window with the specified prerequisites set, whereupon they do what any tasks do in the active window: they check xtriggers if they have any, and trigger once ready.

We can of course add that any use of --pre is equivalent to trigger IF it results in all prereqs being satisfied AND the task has not unsatisfied xtriggers.

@oliver-sanders - if you agree with this, I'll tweak my branch accordingly and close this Issue.

from cylc-flow.

So --recall as an alternative to --pre=all? Note this is a rare use case which I expect will be almost entirely wiped out by #5416.

Hopefully a moot point now, but I'm not sure it will be entirely wiped out by 5416 because we don't know if the user wants the new flow to also start at (e.g.) parentless tasks in future cycles. And there could be several different types of those tasks (clock triggers, and other xtriggers, say, that would make automating it tricky for a new flow as opposed to the original flow.

from cylc-flow.

OK, I'm going to go ahead with this, in order to make progress.

Looking back, I'm near 100% sure that the equivalence of set --pre=all and trigger was just a comment on what seemed like an obvious fact, not a requirement.

In summary, slight change of emphasis on exactly what "set prerequisites" does:

1. it spawns tasks into n=0, and
2. it sets specified prerequisites, if any

If there are any clock-triggers or xtriggers, this will not override them (unlike trigger). This applies for all tasks, so there's no weird special-casing.

Closing as superseded!

from cylc-flow.