Param values under runtime

[hjoliver]

Supersedes #2427

Close #2414

[matthewrmshin]

(Failing PEP8 test on Travis CI.)

[matthewrmshin]

Some quick comments.

[matthewrmshin]

I wonder if it is worth adjusting what REC_P_NAME captures so we don't have to do p_tmpl[1:-1]. (REC_P_NAME is used in another location with a similar logic.)

[matthewrmshin]

I think the code will be easier to understand if we have something like captured_params and used_params.

[matthewrmshin]

(I don't understand why the failed test is failing on Travis CI. It is as if you have already merged master or #2431 into this branch.)

[matthewrmshin]

(In which case, you should have a simple block to convert the regex-captured integer string into an int for int-only parameters.)

[hjoliver]

(yeah that was weird - something was returning an int on Travis CI and a string in my environment. I've rebased to master now).

Still TODO - handle and check whitespace in parameter notation.

[matthewrmshin]

@oliver-sanders please sanity check.

[oliver-sanders]

I find it a little confusing that the following two examples work and are equivalent:

[runtime]
    [[task<param=value>]]
        inherit = FAM<param>

[runtime]
    [[task<param=value>]]
        inherit = FAM<param=value>

Whereas these examples doesn't work:

[runtime]
    [[task<param>]]
        inherit = FAM<param=value>

[runtime]
    [[foo]]
        inherit = FAM<param=value>

[hjoliver]

@oliver-sanders - your first two examples make perfect sense to me, given that what gets expanded/replicated across parameter ranges is task names in the graph and corresponding task definition sections under runtime ... settings underneath a runtime namespace do not get expanded independently, they need to take the value of the parameter in the heading (either implicitly - as before this PR - or explicitly - as on this PR).

I'm trying to figure out if your 3rd and 4th examples makes sense: (3) is it plausible to have all instances of a parameterized task inherit from a single instance of a family that is expanded over the same parameter? and (4) is there a case for a single unparameterized task that inherits from a specific instance of a parameterized family? Maybe we should support those in principle even if they seem unlikely in practice. (4) suggests this though, which is definitely nonsensical:

[runtime]
    [[foo]]
          inherit = FAM<param>

[oliver-sanders]

I'm trying to figure out if your 3rd and 4th examples makes sense

Probably not, though once we set the president that <param=value> can be used anywhere I wouldn't be surprised if we started to see it used everywhere.

is there a case for a single unparameterized task that inherits from a specific instance of a parameterized family

Maybe?

[cylc]
    [[parameters]]
        transport = car, train, plane
[scheduling]
    [[dependencies]]
        graph = """
            start => travel<transport>
            airport_security => travel<transport=plane>
        """
[runtime]
    [start]

    [TRANSPORT<transport>]
        script = # mv
    [TRANSPORT<transport=plane>]
        [[[environment]]]
            FLIGHT_NUMBER=abc001
            TERMINAL=3

    [travel<transport>]
        inherit = travel<transport>
    [airport_security]
        inherit = TRANSPORT<transport=plane>

[oliver-sanders]

Coming back to this we could just put in an error message to cover the latter two cases. The stock error is somewhat misleading:

ERROR, parameter values not supported here: inherit = FAM<param=1>

ERROR, undefined parent for foo: FAM<param=1>

[hjoliver]

@oliver-sanders - based on your example (which is mildly convincing!) I've decided to allow inheritance from any specific parameterized parent. The value of a parameter in the parent name can either be explicit (parent<m=3>) in which case any legal value of the parameter is OK regardless of whether the namespace heading is expanded over that parameter or specified to that value or not; or implicit (parent<m>) in which case the value must be supplied by expansion of the same parameter in the namespace heading ... but anything else is illegal, with better error messages. Tests updated accordingly.

[oliver-sanders]

Looks Good!