Support for aliases in ShellCommandTask specifications

[ghisvail]

Whilst working on pydra-freesurfer, I came across some FreeSurfer interfaces where one could legitimately wonder what the appropriate name for a given field should be. For instance, recon-all provides 4 flags to specify the subject id to process (s, sid, subjid, subject).

One may wonder which one should be picked as the name for the input spec. I'd argue that subject_id is a better name as I value explicitness over conciseness when using higher-level PL like Python. That being said, I am aware this choice will incur a cost to people looking to port their existing scripts (which may use one of these 4 flags).

I was wondering whether pydra could implement support for known aliases for a given field in the input spec.

Something along the lines of:

input_spec = SpecInfo(
    fields=[
        (
            "subject_id",
            str,
            {
                 "help_string": "subject identifier",
                 "argstr": "-s {subject_id}",
                 "aliases": ["s", "subjid", "subject"],
            }
        ),
    ],
)

Which may allow the following instantiations:

task = ReconAll(subject_id="foo")  # The usual
task = ReconAll(s="foo")           # First alias
task = ReconAll(subjid="foo")      # Second alias
task = ReconAll(subject="foo")     # Third alias

This may facilitate porting scripts written with either forms to Pydra.

[satra]

while i'm ok with encoding aliases in the spec, i would prefer not to allow providing the option to the user. it makes code quite unreadable. this was one of the key elements of nipype to only support readable and hopefully semantically useful variable names. it would be a shame to deteriorate to variables that only knowledge can help interpret. also in general we would prefer using the more readable flag in the argstr when available.

[ghisvail]

while i'm ok with encoding aliases in the spec, i would prefer not to allow providing the option to the user. it makes code quite unreadable.

I am not quite sure what the aliases would be useful for then.

Just for documentation purposes you mean?

this was one of the key elements of nipype to only support readable and hopefully semantically useful variable names.

I am also very much in favor for using descriptive names. That being said, I can think of a few interfaces in nipype where this was not totally enforced. Back to my FS example, some long options use abbreviations which are neither descriptive nor documented.

also in general we would prefer using the more readable flag in the argstr when available

It can be quite ambiguous sometimes. Choosing between subjid and subject as the more readable options for subject_id is quite subjective in my opinion. Probably why I picked the wrong one :smile: