Skip to content

Potential replacement to most _list_outputs and/or aggregate_outputs #3149

Open
@oesteban

Description

@oesteban

Summary

The need for implementing _list_outputs and/or aggregate_outputs adds a lot of friction in the creation of new interfaces as these two methods are hard to generate automatically. This design also conflicts with a much-refined design for the inputs.

Since these are hard to automate, interfaces with either one or the other method are difficult to port to a much lighter interface object of Nipype 2.0.

Proposal

  1. Extend metadata / create new traits as follows:
class _OutputSpec(TearUpTraitedSpec):
    out_file = File('{in_file}_processed', mandatory=True, exists=True)
    out_list_glob = FileList(glob='{in_file}_tissue_*', mandatory=True, min=3, max=5)
    out_list_re = FileList(re=r'{in_file}_tissue_\d{3}', mandatory=True, min=3, max=5)
    out_float = Float(stdout=func_callback, mandatory=True)

where the get_value of each trait is modified to perform 1) python formatting replacement with the input names as keyword arguments; 2) run pattern matching (glob or re metadata); and 3) run callbacks to parse standard output or error streams (e.g. that func_callback, which is a python function that takes in the std out and returns a parsed value.

  1. aggregate_outputs is then left as an empty hook for backward compatibility, and instead the output trait is instantiated. TearUpTraitedSpec is a TraitedSpec that fills in all values for the new special traits in its __init__(). The OutputSpec only lives for the same amount of time it used to live before (basically during aggregate_outputs) and gets cached exactly in the same way - i.e. the API does not really change, is just extended.

  2. Most _list_inputs if not all can be removed.

  3. SimpleInterface can be dropped as it won't be necessary anymore.

Interesting side-effects

These new traits would be really interesting, for instance, to minimize the boilerplate of SelectFiles and DataSources because it would also be possible to use them for input specs in an IdentityInterface, effectively finding the given input patterns. (in particular, I'm considering something like this in the context of nipreps/smriprep#107)

WDYT?

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions