Hoping to sense-check on the best way to record the purpose of an app (task) in a suite - I think I can see how to do this with cylc, but wanting to check if there’s a rose way of doing this.
Longer context for this below - TLDR: I want to a mechanism to give a ~explicit, ~easily-discoverable description of a ~complex app’s purpose, so I don’t have to:
- dig deep-down in (say) the app’s scripts, and any documentation I’ve hopefully put there
- rely on encoding this within the app name, already ~long as am trying to stick to the (sensible!) naming convention guidelines, a la
I’ve not yet used it / encountered it much in others’ suites, but hunting for options here, I’ve found cylc’s runtime task metadata items, which look like they might meet my aims - and indeed seem to be recommended by the style guide.
And if documenting apps like this makes the suite.rc too long, I guess I could hive such
description entries off into separate files (e.g. in
./app/my_app/title-description.rc, and use the include file mechanism in the suite.rc in order to:
- actually include this, so this info is made available in the GUI
- expose existence of this file within suite.rc, so those reading suite.rc can discover that title/description info for app exists, and where to look for it
However, before I charge off and do this, wanting to check whether the above approach is sensible? Or whether there’s a way to provide such information via rose instead? Say something similar to the help metadata for a setting, but as metadata recording the purpose of the app?
Asking this as I guess this could be considered part of rose’s “[create] metadata to facilitate ease of use by others” function. And might be especially helpful if (say) you wanted to provide guidance which differentiated between the behaviours of the main rose config and optional configuration(s).
I guess this differentiation could still live in cylc’s
[[[meta]]] entries for the app in suite.rc - e.g.:
[[my-app]] [[[meta]]] title = Install code description = """ Installs code from /foo If optional rose config bar is used, https://baz is used as installation source """
So perhaps a rose route is unnecessary. But just wanted to make sure!
I’m trying to apply the general task naming conventions in a (non-UM) suite, and for purposes of clarity/my sanity, have just ended up changing some app names from my original, more succinct choices to longer ones which more properly describe what’s going on, to help me visually parse & understand the graph / suite.rc file. So I’ve gone from:
(the apps wrap some 3rd-party makefiles for 3rd-party model. Makefiles only expose the
config-compile options. I prefer not to delve into innards, to expose the individual
test components, as I don’t want to shoulder maintenance burden if/when innards change)
However, these new names, while more explicit, are much longer, and go ~against the “keep names as short as possible” guidance. Hence keen to see what other options I could use for purpose, allowing terser names for the apps/tasks (e.g. a cryptic