install: add install options to other source workflow commands

[oliver-sanders]

(kinda a cylc-rose issue, however, could apply to other plugins and might require some legwork in this repo so creating here)

Via the cylc-rose plugin we can specify things like optional configs to cylc install, however, we cannot do so with other commands like cylc validate and cylc config.

Take for example this workflow which has a compulsory optional configuration (It's not unusual for workflows to require one opt config to be specified):

# rose-suite.conf

# ops/rose-suite-myopt.conf
[template variables]
ICP = "20000101T0000Z"

# flow.cylc
#!Jinja2

[scheduling]
    initial cycle point = {{ ICP }}
    [[graph]]
        R1 = foo

This works:

$ cylc install -O myopt
$ cylc validate <workflow>

This does not:

# there is no way of specifying the optional config to cylc valiate
$ cylc validate .

Questions:

• Should the cylc-rose install options be available to validate and config?
• Should they apply to any other commands?
• Is there a nice way to define the install options that are applicable to the offline commands (i.e. -O) as opposed to the ones which aren't (e.g. --no-run-name)?

Pull requests welcome!

[wxtim]

Should the cylc-rose install options be available to validate and config?

I think that either:

• if users are rying to run these CLI apps on non-installed workflow folders the app should return an error.
• we should bake plugin support to all these apps
• Alternatively we add a -- option to like we did with rose suite-run to pass to install, install in a temporary file and run the app on:

cylc validate ~/cylc-src/myflow/flow.cylc   # Validate without installation - consequences belong to user
cylc validate ~/cylc-src/myflow/flow.cylc -- -O my_opt_conf  # Run cylc install and validate the installed WF.

---

Should they apply to any other commands?

List of commands where there may be a case for adding Plugin information:

CLI apps I considered and dismissed:

• edit - I think that we aren't encouraging the use of this any-more, and probably don't want to try and fold this in. It could be nasty.
• search - Just works. Doesn't try to do any expansion. Why do we even offer this, it just feels like extra stuff to maintain.
• show - Appears to be running suites only?

CLI options which almost certainly need to be addressed:

• install - This should already be sorted by the original work on Cylc-Rose.
• config
• validate: If you can't validate an uninstalled workflow users will either
  • Get annoyed by install → validate → clean → make changes workflow
  • Fill every workflow install dir with 100s of runX folders, risking confusion later.

CLI options which might need to be addressed:

(It might be ok to get these to throw big red warnings if people try to use them on source folders?)

• graph - Seems likely that you'd want to do this.
• view - View a processed workflow configuration - probably not, given the description, but shouldn't work on source files?
• list - What is the use case for this? Without knowing I have no idea what we want to do with it.
• diff - Presumably to be used on installed workflows? It works on source files fine, if the users aren't worried about the expansions, and I guess that if they are then they can install?

[oliver-sanders]

List of commands where there may be a case for adding Plugin information:

This would only apply to commands which need to parse the flow.cylc file so that excludes things like edit and view so from your list I think that leaves us with:

• config
• validate
• graph
• list

Four commands, that's not too bad.

• if users are rying to run these CLI apps on non-installed workflow folders the app should return an error.
• we should bake plugin support to all these apps

These comments seem to contradict? Are you saying we should or shouldn't support the -O arg for other commands?

list - What is the use case for this? Without knowing I have no idea what we want to do with it.

$ cylc help list
Usage: cylc list [OPTIONS] WORKFLOW 

List tasks and families defined in a workflow.

[wxtim]

These comments seem to contradict? Are you saying we should or shouldn't support the -O arg for other commands?

Listed possible opinions.

[oliver-sanders]

Aah

[wxtim]

I was incorrect to state that #4293 doesn't close this.