Skip to content

Compatibility with nibabel 4.0.0 #3486

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

Closed
2 tasks
HippocampusGirl opened this issue Jul 6, 2022 · 2 comments · Fixed by #3488
Closed
2 tasks

Compatibility with nibabel 4.0.0 #3486

HippocampusGirl opened this issue Jul 6, 2022 · 2 comments · Fixed by #3488

Comments

@HippocampusGirl
Copy link
Contributor

Actual behavior

nipype uses the now removed nibabel.trackvis interface, which leads to a ModuleNotFoundError.

from nibabel.trackvis import HeaderError

│     ---- (full traceback above) ----
│     File "/usr/local/miniconda/lib/python3.10/site-packages/fmriprep/cli/workflow.py", line 82, in build_workflow
│         retval["workflow"] = init_fmriprep_wf()
│     File "/usr/local/miniconda/lib/python3.10/site-packages/fmriprep/workflows/base.py", line 64, in init_fmriprep_wf
│         single_subject_wf = init_single_subject_wf(subject_id)
│     File "/usr/local/miniconda/lib/python3.10/site-packages/fmriprep/workflows/base.py", line 304, in init_single_subject_wf
│         func_preproc_wf = init_func_preproc_wf(bold_file)
│     File "/usr/local/miniconda/lib/python3.10/site-packages/fmriprep/workflows/bold/base.py", line 419, in init_func_preproc_wf
│         bold_sdc_wf = init_sdc_estimate_wf(fmaps, metadata,
│     File "/usr/local/miniconda/lib/python3.10/site-packages/sdcflows/workflows/base.py", line 154, in init_sdc_estimate_wf
│         from .fmap import init_fmap2field_wf
│     File "/usr/local/miniconda/lib/python3.10/site-packages/sdcflows/workflows/fmap.py", line 29, in <module>
│         from .gre import init_fmap_postproc_wf, init_magnitude_wf
│     File "/usr/local/miniconda/lib/python3.10/site-packages/sdcflows/workflows/gre.py", line 17, in <module>
│         from niflow.nipype1.workflows.dmri.fsl.utils import cleanup_edge_pipeline
│     File "/usr/local/miniconda/lib/python3.10/site-packages/niflow/nipype1/workflows/dmri/__init__.py", line 4, in <module>
│         from . import camino, mrtrix, fsl, dipy
│     File "/usr/local/miniconda/lib/python3.10/site-packages/niflow/nipype1/workflows/dmri/mrtrix/__init__.py", line 3, in <module>
│         from .diffusion import create_mrtrix_dti_pipeline
│     File "/usr/local/miniconda/lib/python3.10/site-packages/niflow/nipype1/workflows/dmri/mrtrix/diffusion.py", line 5, in <module>
│         from nipype.interfaces import mrtrix as mrtrix
│     File "/usr/local/miniconda/lib/python3.10/site-packages/nipype/interfaces/mrtrix/__init__.py", line 36, in <module>
│         from .convert import MRTrix2TrackVis
│     File "/usr/local/miniconda/lib/python3.10/site-packages/nipype/interfaces/mrtrix/convert.py", line 6, in <module>
│         import nibabel.trackvis as trk
└─    ModuleNotFoundError: No module named 'nibabel.trackvis'

Expected behavior

There should not be an error.

My suggestions

  • Update the requirements.txt to indicate a lack of compatibility with nibabel 4.0.0,

nibabel>=2.1.0

  • Find out where the removed interfaces were used, and replace them.

How to replicate the behavior

I'm skipping this for now, because I think the issue is obvious from the code. If I'm mistaken, please let me know and I will edit to add some steps.

Script/Workflow details

This happens when using fMRIPrep LTS with HALFpipe.

Platform details:

I am skipping this for now, since I believe the issue is unrelated to my platform. Please let me know if you require this information.

Execution environment

Container downloaded from https://download.fmri.science/singularity/halfpipe-halfpipe-latest.sif

@HippocampusGirl HippocampusGirl changed the title Compatibility with nibabel 4.0.0 Compatibility with nibabel 4.0.0 Jul 6, 2022
HippocampusGirl added a commit to HALFpipe/HALFpipe that referenced this issue Jul 6, 2022
@effigies
Copy link
Member

effigies commented Jul 6, 2022

I think it makes more sense to make it a runtime error instead of import time. Most people will not be using this interface. So we move the import into the method that calls it, and wrap it with a try/except ImportError to give a more helpful error message.

@HippocampusGirl
Copy link
Contributor Author

Thank you :-)

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

Successfully merging a pull request may close this issue.

2 participants