Skip to content

Inconsistent behavior of inputs with name_template #1381

Open
@oesteban

Description

@oesteban

Some interfaces are coded as follows: either they define an input as traits.Either(traits.Bool, traits.File) or they explicitly have a traits.Bool input and a traits.File input.

The idea is that the boolean input enables parsing the file and add it to the command line. Many times these filenames are generated automatically, using the genfile feature.

The genfile approach works because the developer has to explicitly code the name resolution and the outputs filling by overloading the _gen_filename and _list_outputs methods. The name_template approach fails because it automatically forwards the input to the output within the aggregate_outputs method. The workaround is: 1) use different names for the input and output traits and 2) hard code the input forwarding in the _list_outputs.

I think this is not very intuitive, and we need to define a standard behavior for this situation that happens oftentimes in, for instance, FSL.

Additionally, we've been working on unifying the name_template feature and the genfile feature. I think we can agree that name_template is probably more comprehensive and easy to use. However, it requires agreeing on some conventions about how to automate the inputs and outputs processing. I raised this as a question in #1371 .

I open this issue is to make this particular (and current) problem explicit.

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