Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rapidtide interface #9

Open
tsalo opened this issue Sep 3, 2024 · 2 comments
Open

Rapidtide interface #9

tsalo opened this issue Sep 3, 2024 · 2 comments

Comments

@tsalo
Copy link
Collaborator

tsalo commented Sep 3, 2024

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
Copy link
Collaborator

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
Copy link
Collaborator Author

tsalo commented Sep 4, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants