substitutions inside a default don't quite work for sub-recipes

[o-smirnov]

See tron-breifast for an example.

The breifast subrecipe defines two particular inputs:

    cube:
      dtype: Directory
      required: true
      info: raw (highest) time cadence cube (as .zarr)
    cube-fits:
      dtype: File
      info: raw (highest) time cadence cube (as .fits)
      default: '{current.cube}.fits'

In principle only cube should be needed. However, if the recipe is a sub-recipe of another recipe like so:

  steps:
    breifast:
      recipe: breifast
      params:
          cube: =steps.stack-cube-htc.convolved-cube

then during the prevalidation of the step, current.cube itself is a substitution that's not yet valid at prevalidation time. The substitution error gets frozen into the prevalidated dict. The cube setting is updated by this line, but since cube-fits is not a parameter, it doesn't get updated and ends up throwing the substitution error upwards.

Workaround: specify cube-fits at the step definition.

Proper solutions:

• anything that's unresolved at prevalidation time should be tossed out from the prevalidated dict when validating the step prior to execution.

• or, any default setting in the cargo should be copied into the step's param dict (because then it is always revalidated).

[o-smirnov]

Also related -- should a subrecipe default allow lookup in recipe (referring to itself?) This arises in make_masks in parrot-stew-recipes. Also happens if an alias picks up a default from a step definition referring to recipe.