Do not open nifti files with mmap if numpy < 1.12.0 #1796
Conversation
Codecov Report
@@ Coverage Diff @@
## master #1796 +/- ##
==========================================
+ Coverage 69.82% 69.84% +0.02%
==========================================
Files 1047 1047
Lines 52133 52161 +28
Branches 7669 7669
==========================================
+ Hits 36403 36433 +30
+ Misses 14142 14140 -2
Partials 1588 1588
Continue to review full report at Codecov.
|
.travis.yml
Outdated
| # Add install of vtk and mayavi to test mesh (disabled): conda install -y vtk mayavi && | ||
| - function inst { | ||
| - function conda_inst { | ||
| export CONDA_HOME=/home/travis/anaconda && |
There was a problem hiding this comment.
@oesteban - sorry if this was somehow my fault - but why did we switch to anaconda? miniconda gives us everything we need right?
There was a problem hiding this comment.
@satra I was just checking if switching to anaconda made any difference as regards the segmentation fault, but I'm arriving to the conclusion that miniconda is much better for travis. So there's no point on switching.
|
Ok, all-green lights on travis. It seems to me that conda has changed the way python should be downgraded. I was experimenting problems with python 3.4 not being downgraded. Now that should be fixed. I have also split the install commands, to make it more granular: one for the apt stuff and a second for miniconda (still miniconda). Other than that, this PR should get us away the casting problems while we can't enforce numpy>=1.12 |
|
@oesteban - quick question - would this affect all routines where we use nibabel? if so should we do this globally? and is this something nibabel is handling automatically now? i.e. if we change version of nibabel to current master this would be ok? the reason i ask is that there is going to be a release of nibabel quite soon. |
|
Hi @satra, at some point I had trouble with the version pinning of nibabel (https://travis-ci.org/nipy/nipype/jobs/198184510) and removed it. I'm to check if this is happening now. However, I'd try not to set versions of packages unless we are truly sure that we need specific features that were not implemented in old versions. Finally, we need to define more specific rules for maintaining dependencies (please see nipreps/niworkflows#117 (comment)) As regards deployment, the version specification for nibabel is still there (https://github.com/nipy/nipype/blob/master/nipype/info.py#L105). This means that for nipype installed through pypi, it will request nibabel>=2.0.1. So the changes we make to the requirements.txt only affect development environments or special. This means that the operator should know what they are doing. Therefore, unless there are very strong reasons to enforce a package version (like traits>=4.5), in the requirements.txt we should not specify that (or, maybe better, we should try to have an empty or almost empty requirements.txt). If you want to pin a package to the master branch of a repo, the requirements.txt is the place to do it. You can also try for the released pypi distribution, but so far, I've seen it working out only when no pypi package is available and there is no other option that the For peace of mind reasons, I will reset the nibabel version on the requirements.txt until we know better what to do. |
|
this is ready to merge :) |
|
happy to merge this, but should we open an issue that does this for any place where nibabel load is used? it's used in most of the routines in |
|
Ok, wait a minute :) - using a regex to replace all easy appearances. Those more complicated (i.e. without the package alias |
|
@satra there you go, all (I think none escaped the revision) the |
Fixes #1795