You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
Some interfaces are coded as follows: either they define an input as
traits.Either(traits.Bool, traits.File)
or they explicitly have atraits.Bool
input and atraits.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. Thename_template
approach fails because it automatically forwards the input to the output within theaggregate_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 thegenfile
feature. I think we can agree thatname_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.
The text was updated successfully, but these errors were encountered: