tl;dr: I think I’ve addressed all of your questions below, though perhaps not satisfactorily or in order. Basically, you’re welcome to use niworkflows (caveat emptor), but what would probably be most valuable for everybody is figuring out how to upstream the useful bits.
So niworkflows is a couple things, including a staging ground for interfaces and small workflows that we might want to merge into nipype one day. But most importantly, it’s what we need to make fmriprep and mriqc work, which includes updates to nipype on a much shorter time scale than nipype’s release cycle. We certainly intend everything in it to be open and reusable, but it should be understood to depend on features that are not in a released version of nipype, and we’ve intentionally sacrificed usability of niworkflows as a library for the smooth installation of fmriprep and mriqc.
As you’ve noticed, it is not interoperable with a separate installation of nipype. (It shouldn’t interfere – this was another reason for the choicese we made – but
niworkflows.nipype are just not going to work together.) This could be eventually resolved by moving to a duck-typing approach to nipype; instead of checking whether objects are an instance of a class, we could just require that they implement an interface. But I digress, since that’s not going to help you right now.
The easiest way to use niworkflows with existing pipelines is to simply replace
niworkflows.nipype everywhere you see it in your existing code. There’s the possibility of breakage, since the most recent niworkflows release includes nipype master as of 16 days ago. And of course, now your code is dependent on
niworkflows.nipype, etc, etc.
What would probably be the most useful way forward is to consider how we can integrate the features you want back upstream into niworkflows proper. Our visualization interfaces could plausibly become part of nipype, but we’d need input from the wider community to make them less specific to our use cases. And any other interfaces that you particularly find valuable, we can prioritize moving those over (and any help you have time to give beyond simply identifying those interfaces would be invaluable).
The nodes you see “rewritten” are (for the most part) drop-in replacements for the originals that include reporting automatically. e.g.
BBRegister, but it also generates an SVG showing the quality of registration, using the inputs and outputs of the interface.
And because I like to maintain links to an ongoing discussion so that if I miss something people can read the whole history:
(To be clear, I’m not saying you should have dug this up. I just want to make it easier for me to dig it all up next time it comes up, because this has bitten people a number of times.)