Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

parameterization: make parameters avaliable to other suite.rc sections #2453

Open
ColemanTom opened this issue Oct 19, 2017 · 4 comments

Comments

@ColemanTom
Copy link
Contributor

commented Oct 19, 2017

If possible, I think it could be useful to extend the parameterizing mechanism for task names to be usable for custom messages for triggering purposes.

e.g.

graph = """
foo:out_1 => bar_1
foo:out_2 => bar_2
foo:out_3 => bar_3
"""

Could simplify to:

graph = "foo:out<n> => bar<n>"

Similarly

[[some_polling_task]]]
    [[[output]]]
        out_1 = "message_1"
        out_2 = "message_2"
        out_3 = "message_3"

Becomes:

[[some_polling_task]]]
    [[[output]]]
         out<n> = "message<n>"

NOTE: I'm relatively inexperienced with Cylc, so these may not be the most Cylc-y way of doing things. If there are better approaches to take I would welcome them.

Regards,
Tom

@matthewrmshin matthewrmshin added this to the later milestone Oct 19, 2017

@oliver-sanders

This comment has been minimized.

Copy link
Member

commented Oct 19, 2017

Updating the title of this issue to reflect the broader issue of parameters not being available throughout most of the cylc configuration. Parameterizations, currently, can only be used in the graph, inherit and script (via an environment variable) items.

@oliver-sanders oliver-sanders changed the title Feature idea: Ability to use parameter mechanism for custom messages parameterization: make parameters avaliable to other suite.rc sections Oct 19, 2017

@hjoliver

This comment has been minimized.

Copy link
Contributor

commented Oct 19, 2017

Expanding on Oliver's point a bit - current use reflects the fact that suite parameters are exclusively for parameterizing task names, not a general parameterization mechanism. However I think @ColemanTom's suggestion on this issue is a very natural extension. And then #2456 takes it even further...

@hjoliver

This comment has been minimized.

Copy link
Contributor

commented Oct 9, 2018

@hjoliver

This comment has been minimized.

Copy link
Contributor

commented Aug 5, 2019

@trwhitcomb has posted another suggestion on Discourse: it would be useful to have parameterised external triggers. https://cylc.discourse.group/t/parameterized-clock-triggers/114

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.