Rapidtide interface

[tsalo]

I'm trying to figure out the best way to create a rapidtide nipype interface for the workflow. Unfortunately, the way it's structured on rapidtide's end makes that difficult. Here are a few options I'm considering:

1. A BaseInterface: basically call rapidtide as a Python function.
   • The biggest problem here is that rapidtide_main just isn't structured in a way that would work with this, AFAICT. The input to rapidtide_main is an argparse function, so it's really only set up to be called as a command-line interface.
   • I need to know the individual parameters for this kind of interface.
   • Also, passing along a massive dictionary makes it hard to keep track of what parameters are actually used and where. @bbfrederick how would you feel about splitting up optiondict and theprefilter into individual parameters?
2. A Function interface: call rapidtide as a Python function with minimal knowledge of inputs and outputs.
   • In this approach we can pass in the parameters are keyword arguments, which means the function still needs to have individual parameters, but we don't need to define all those parameters in an InputSpec.
3. A command-line interface: Call rapidtide as a command-line interface.
   • I need to define all of the individual parameters that we might need, but other than that this seems like the most doable option.

[bbfrederick]

I'm open to making changes - I'm not super happy with the interface to rapidtide that has... accreted over the years, and I don't like throwing optiondict all over the place - that's basically having global variables by another name.

One concern is - how do I efficiently make a function call with named keywords that stays in sync with the gargantuan argument parser? For my own reasons, I like having fine grained control over how operates via command line arguments, although I do see that it's gotten a bit out of hand. Is there a standard way of doing this that I should be conforming with?

[tsalo]

how do I efficiently make a function call with named keywords that stays in sync with the gargantuan argument parser?

Normally I'd just have all of the keywords in there, even if there are a ton. Maybe you could have something like fMRIPrep's config object? It's essentially a global dictionary, but one key thing is that you wouldn't modify it after initializing it.