One of my suites has a jinja2 section at the start of the suite.rc file which does a lot of variable setting based on other jinja2 variables set elsewhere (in a rose-suite.conf). A simplified version of part of it would look something like
If I happen to set a non-valid value of SUITE-RESOLUTION then cylc validate will crash out as expected but with a non-helpful (for the general user) error message. Is there a way of getting cylc validate to raise an error with a meaningful message? I doubt there is but I thought I would ask of the wise.
If not does anyone have any other suggestions as to how to make the desired failure less of a mess? Something in the {% else %} section perhaps?
I’m not sure I see the problem. From what you’ve written, there isn’t any “non-valid value of SUITE_RESOLUTION” because you have an {% else %} block to catch everything other than “low”, “medium”, and “high”. The only way I can trigger a Jinja2 error is to not set SUITE_RESOLUTION at all, which results in a pretty clear message:
Jinja2Error:
File "<template>", line 2, in top-level template code
UndefinedError: 'SUITE_RESOLUTION' is undefined
Context lines:
{% if SUITE_RESOLUTION == "low" %} <-- Jinja2Error
Do you mean the else block should abort with an error message because only low, medium, and high are valid?
{% else %}
{{ raise("invalid value of SUITE_RESOLUTION: " + SUITE_RESOLUTION) }}
{% endif %}
Then:
$ cylc validate --set="SUITE_RESOLUTION=huge" mt
Jinja2 Error: invalid value of SUITE_RESOLUTION: huge
I have a similar thing in one of my rose/cylc suites. In my case I am deciding which .rc file (containing site-specific settings) to include, based on a SITE variable in the rose-suite.conf file:
{% if SITE == 'met' %}
%include 'site_rc/suite-runtime-met.rc'
{% elif SITE == 'uni' %}
%include 'site_rc/suite-runtime-uni.rc'
{% elif SITE == 'ofc' %}
%include 'site_rc/suite-runtime-ofc.rc'
{% else %}
{{ "ERROR: unknown SITE value!"/0 }}
{% endif %}
When validating with an invalid SITE value you’ll see that as an ERROR in the shell.
Not very elegant, but it works as a reminder.
Yeah that’s another approach. It works because your Jinja2 print statement {{ "ERROR ...." }} prints a string ("ERROR ...") that is not valid a Cylc configuration item, so the config parser will abort and print the invalid line.
Yes that approach was similar to what I was trying previously. Having a meaningful error message is important for users who don’t like/want to unpick the automatic and cryptic that cylc validate can produce in such circumstances.