Closed chamberm closed 1 year ago
@jhlegarreta - something easily fixable?
@chamberm Having a look now. The issue seems to be the dependencies in the Binder instance: a recent NumPy vs. an incompatible DIPY version. So far from the Binder instance launch logs:
Updating specs:
- git
- dipy=1.3.0
- fury=0.6.1
- jupyter_contrib_nbextensions
- matplotlib
- nibabel
- nilearn=0.7.0
- numpy
- osfclient
- pandas
- seaborn
- python=3.8
- pip
blob:https://mybinder.org/69487d9d-0637-4d92-af86-653c02c1494d
dipy 1.3.0 py38h0b5ebd8_1 conda-forge/linux-64 8MB
(...)
numpy 1.24.3 py38h59b608b_0 conda-forge/linux-64 7MB
NumPy made changes to the basic types, introducing deprecation warnings, in version 1.20.0: https://numpy.org/devdocs/release/1.20.0-notes.html#deprecations
Which probably were meant to raise errors after some release cycles.
DIPY 1.3.0 only enforced numpy>=1.12.0
.
And clearly, the Binder instance is installing both DIPY and NumPy versions that are not the ones in the current requirements.txt
file.
So we need to find the way for Binder to pull from the packages versions from the current requirements.txt
file, or else, update them manually. If you have done that in the past, please go ahead. Otherwise, I will try to have a look as time permits.
And clearly, the Binder instance is installing both DIPY and NumPy versions that are not the ones in the current requirements.txt file.
This repository uses a binder/environment.yml
file and I think the version numbers need to be updated there.
The requirements.txt
file was updated ~6 months ago, specifying dipy==1.5.0
(and 1.4.1 before that) but binder/environment.yml
is still asking for dipy
version 1.3.0.
This repository uses a binder/environment.yml file and I think the version numbers need to be updated there.
The requirements.txt file was updated ~6 months ago, specifying dipy==1.5.0 (and 1.4.1 before that) but binder/environment.yml is still asking for dipy version 1.3.0.
@tobyhodges thanks for having cast light on this :100: !
PR #227 synchronizes the Binder
environment package versions. Unless one starts a local Binder
instance, I guess there is no way to have this tested until we merge the PR. The CI is likely to time out trying to install FSL, so I will merge unless @chamberm says he can test this locally.
Other than that, @chamberm the next issue you may run into when using the cloud hosted Binder
instance is difficulty in running the notebooks due to its limited memory (2 GB). We have been unable to set up a solution in place so far :roll_eyes:.
You can go ahead - we can test online. This will be the primary use on my side for students.
You can go ahead - we can test online. This will be the primary use on my side for students.
Thanks Maxime. Merged. Please close the issue if the merged PR fixes it; otherwise, I'll do it myself after a reasonable period, as I consider the issue fixed. Feel free to open other issues as you encounter them.
I'll try to make steps forward to improve things as time permits. Last but not least, many thanks for your interest.
At least Binder looks to be setting up the environment and launching the notebooks correctly now (have not run them)
A few days have elapsed; I am going ahead and closing the issue, as the primary error reported here was fixed.
I am running the online Binder version and this occurs within the first few lines - any tips?