Strip SDC workflows off of fMRIPrep

[oesteban]

SDC workflows should not impose the full fmriprep as a dependency.

This will indirectly make it easier to address #1469, and potentially create a small CLI to allow running SDC directly on prescribed inputs (ie., after preprocessing, not BIDS-compliant). That would allow a more agile evaluation of SDC (cc @mattcieslak).

[effigies]

Niworkflows is not super light:

REQUIRES = [
    'jinja2',
    'matplotlib>=2.2.0',
    'nilearn>=0.2.6,!=0.5.0,!=0.5.1',
    'nipype>=1.1.6',
    'packaging',
    'pandas',
    'pybids>=0.7,<0.8',
    'PyYAML',
    'scikit-image',
    'scipy',
    'seaborn',
    'svgutils',
    'templateflow<0.2.0a0,>=0.1.7',
]

It might be worth breaking these things into extras. A lot of that could be bundled into a reports extra.

[oesteban]

I agree. But to keep things in scope I'd propose to first move to NIWorkflows (which is lighter than fmriprep) and open an issue there trying to modularize that beast.

If isolation of SDC workflows is well designed, it should be trivial to move it wherever we like (e.g., as and independent niflow) and strip it off of niworkflows.

WDYT?

[oesteban]

On the other hand, providing some kind of independent workflow would make testing and benchmarking a lot more agile (I'm thinking of your use-case, @mattcieslak)

EDIT: another plus is that we can add collaborators to the project without them having access to the whole niworkflows.

[effigies]

Sure.

[mattcieslak]

Are you proposing a new repository just for SDC workflows or adding a module to niworkflows? I've had some difficulty with niworkflows as a dependency of qsiprep because it changes so frequently. It might be nice to have a stand-alone set of SDC workflows that will be mostly frozen after we optimize the fieldmapless method. I'd defer this decision to you guys though

[oesteban]

Yeah, after reflecting a bit I'm convinced now that an independent repo will be best.