MAINT: bump templateflow to auto-update skeleton

[mgxd]

This bumps the minimum templateflow to 0.6.0, which includes an automatic update mechanism to update the local template skeleton.

This should reduce the burden of having to update the python templateflow client every time a change has been made to the skeleton.

[mgxd]

it looks like sdcflows 1.2.3 introduces an error with the doc build

Warning, treated as error:
/usr/local/lib/python3.7/site-packages/fmriprep/workflows/base.py:docstring of fmriprep.workflows.base.init_fmriprep_wf:10:Exception occurred in plotting api-1
 from /tmp/src/fmriprep/docs/api.rst:
Traceback (most recent call last):
  File "/usr/local/lib/python3.7/site-packages/nipype/sphinxext/plot_workflow.py", line 474, in run_code
    exec(code, ns)
  File "<string>", line 49, in <module>
  File "/usr/local/lib/python3.7/site-packages/fmriprep/workflows/base.py", line 274, in init_fmriprep_wf
    bids_filters=bids_filters,
  File "/usr/local/lib/python3.7/site-packages/fmriprep/workflows/base.py", line 638, in init_single_subject_wf
    use_syn=use_syn,
  File "/usr/local/lib/python3.7/site-packages/fmriprep/workflows/bold/base.py", line 688, in init_func_preproc_wf
    fmap_unwarp_report_wf = init_sdc_unwarp_report_wf()
  File "/usr/local/lib/python3.7/site-packages/sdcflows/workflows/outputs.py", line 46, in init_sdc_unwarp_report_wf
    from niworkflows.utils.images import dseg_label as _dseg_label
ImportError: cannot import name 'dseg_label' from 'niworkflows.utils.images' (/usr/local/lib/python3.7/site-packages/niworkflows/utils/images.py)

[oesteban]

You'll need to pin niworkflows instead (nipreps/niworkflows@34b40c4#diff-d2098e59c3e86fab94a1afb30f4dfefeR112)

niworkflows >= 1.2.0rc4, < 1.3
sdcflows ~= 1.2.3

[mgxd]

sure we could, but didn't we create #2054 as a reference for our dependency tree?

[oesteban]

Okay sorry, this pr is not against master

[mgxd]

if this looks good, I'd like to get this out and cut a new release for the 20.0.x series

[oesteban]

go for it :)

[effigies]

So, wait, we released an incompatible version of sdcflows in the 1.2.x series? Should we delete it from PyPI and re-release as 1.3.0?

[mgxd]

that would probably be the cleanest way to ensure we could still update sdcflows in the 20.x series.

[oesteban]

I think getting back to compatible only requires reinserting a function definition aliasing the one failing

…

On Mon, May 4, 2020, 07:19 Mathias Goncalves ***@***.***> wrote: that would probably be the cleanest way to ensure we could still update sdcflows in the 20.x series. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2115 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAESDRSWPIF4VAE6ETZOZXTRP3FHDANCNFSM4MXKON7Q> .

[effigies]

So looks like we should delete 1.2.3, branch maint/1.2.x off of 1.2.2, and re-release 1.2.3 as 1.3.0.

Is there any good reason to base 1.2.4 off of the current master?

[mgxd]

the sdc reportlet looks funky

https://13588-53175327-gh.circle-artifacts.com/0/tmp/ds210/derivatives/fmriprep/sub-02.html

@oesteban any ideas here?

[mgxd]

things are working, and reports look comparable to 20.0.6 release CI, so i'm going to merge here

[effigies]

I think the ds210 weirdness is related to --t2s-coreg, which we're deprecating anyway. It exists prior to #2109 in master and goes away after.