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
Pull upstream ivadomed
changes that let us upgrade previously-pinned versions of dipy
/numpy
/nibabel
#4332
Merged
joshuacwnewton
merged 19 commits into
master
from
jn/4319-fix-ivadomed-dependency-conflict
Mar 19, 2024
Merged
Pull upstream ivadomed
changes that let us upgrade previously-pinned versions of dipy
/numpy
/nibabel
#4332
joshuacwnewton
merged 19 commits into
master
from
jn/4319-fix-ivadomed-dependency-conflict
Mar 19, 2024
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
joshuacwnewton
commented
Jan 10, 2024
joshuacwnewton
commented
Jan 23, 2024
joshuacwnewton
changed the title
Test upstream
Update Mar 12, 2024
ivadomed
changes to avoid dependency conflicts with dipy
ivadomed
to allow us to upgrade to the newest versions of dipy
and numpy
This incorporates the merged changes from ivadomed/ivadomed#1308, which allow use to upgrade dipy and numpy.
This wasn't possible before, but with the upstream ivadomed changes, we can now allow newer versions of dipy.
On 64-bit systems, creating a dummy image with `dtype=int` will result in `int64` images. But, `nibabel` doesn't recommend using `int64` due to compatibility issues, so we explicitly specify `int32` when creating dummy images.
In addition to what the "pystrum" comment says, there is an additional reason why we have been pinning numpy: an incompatibility with our old pin of `dipy==1.5.0` (See: #4314 (comment)) Now that we've upgraded to `dipy==1.8.0` and above, we can safely unpin `numpy` too.
joshuacwnewton
force-pushed
the
jn/4319-fix-ivadomed-dependency-conflict
branch
from
March 15, 2024 01:49
3e84a2f
to
67b1f6b
Compare
This commit is to test whether there is a meaningful difference between dipy==1.8.0 and dipy==1.9.0. It's possible that this has an effect on the stalling test, but it's also possible that the stalling tests were entirely flukes due to model-downloading timeouts. If this commit and the previous commit both pass, then `dipy` makes no difference. But if this commit passes and the previous one fails, then `dipy` does make a difference.
joshuacwnewton
commented
Mar 15, 2024
joshuacwnewton
changed the title
Update
Pull upstream Mar 15, 2024
ivadomed
to allow us to upgrade to the newest versions of dipy
and numpy
ivadomed
changes that let us upgrade previously-pinned versions of dipy
/numpy
/nibabel
These files were erroneously triggering CI failures for the "fake" git links.
6 tasks
joshuacwnewton
commented
Mar 18, 2024
A new release (ivadomed v2.9.10) has been created containing all of the changes from the master branch. So, we can just install the newest version from PyPI.
The `sct_deepseg_gm` test uses dummy input, which results in the `ort_sess.run` function returning `nan` as output. This then causes a `RuntimeWarning: invalid value encountered in cast` when postprocessing the output. So, to be explicit about these nan values, I'm replacing them with 0 (which would have been done anyway during the casting): >>> np.array(np.nan).astype(np.uint8) <input>:1: RuntimeWarning: invalid value encountered in cast array(0, dtype=uint8)
Addresses FutureWarning: https://stackoverflow.com/a/74948596
This is following the direct instructions of the warning message: DeprecationWarning: `np.math` is a deprecated alias for the standard library `math` module (Deprecated Numpy 1.25). Replace usages of `np.math` with `math`
This test currently doesn't work as intended: #4405 The test itself is of minimal importance, since it tests a nonsense input (-initz -1) that shouldn't be used in normal processing.
We catch the "in divide" message, but we don't catch the "in scalar divide" warning. Tracked in #4407.
This was fixed upstream. (wandb/wandb#6711)
joshuacwnewton
force-pushed
the
jn/4319-fix-ivadomed-dependency-conflict
branch
from
March 18, 2024 21:45
1f57611
to
91b0e69
Compare
This reverts commit 91b0e69.
I had mistakenly thought this was resolved (because `wandb` did indeed resolve it on their end), but this is still not resolved for `monai`. I have reported this upstream: Project-MONAI/MONAI#7559
joshuacwnewton
commented
Mar 19, 2024
mguaypaq
approved these changes
Mar 19, 2024
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great work, thanks. It almost feels like spring cleaning! I'll add a commit in a few minutes (see comment below), then it should be good to merge.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Upstream ivadomed changes: ivadomed/ivadomed#1308
The upstream changes enabled a cascade of version upgrades (compared to
master
):requirements.txt
):nibabel
:3.2.2
->5.2.1
dipy
:1.5.0
->1.8.0
numpy
:1.23.5
->1.26.4
pandas
:1.4.4
->1.5.3
pyparsing
:2.4.7
->3.1.2
Given that we've been held back on these versions for so long, some additional changes are needed to address upstream deprecation warnings and errors, mainly due to
numpy
.Linked issues
Fixes #4319.
Mostly addresses #4408, but doesn't address #4408 (comment).