SCT v5.8 ships with ivadomed==2.9.7 which contains a fatal bug for sct_deepseg

[joshuacwnewton]

A user on the forum reported the following issue: https://forum.spinalcordmri.org/t/error-in-seg-tumor-t2-task/1099

The bug is within ivadomed, and causes sct_deepseg to crash. (Note: This issue only affects 3D deepseg models, and not slicewise (2D) deepseg models. Off the top of my head, I don't know what % of our models are 3D and what % are 2D.)

The error that the user encountered is one that has already been reported upstream and fixed: ivadomed/ivadomed#1213. Thus, this is easily fixed by upgrading ivadomed, preferably with the --no-deps option to preserve the rest of the SCT v5.8 environment.

We could backport this fix by bumping the version of ivadomed in 5.8's requirements-freeze.txt. The tricky thing here is ivadomed's dependencies: Is it possible to bump only ivadomed, and leave the other dependencies fixed? Or does ivadomed have strict dependency pinning that makes this impossible? (Assuming there are even meaningful dependency changes between ivadomed v2.9.7 and ivadomed v2.9.8.)

[mathieuboudreau]

The tricky thing here is ivadomed's dependencies: Is it possible to bump only ivadomed, and leave the other dependencies fixed? Or does ivadomed have strict dependency pinning that makes this impossible?

In our experience over in AxonDeepSeg, I think we've experienced first of these two things, but I believe because we're installing most of our packages with conda (which strictly enforces requirements) and then ivadomed with pip (which doesn't strictly enforce the versions), using the same environment package. See this snippet in a PR I opened on IVADOMED recently ivadomed/ivadomed#1292 (comment).

SCT does it's installation quite differently than us, so maybe IVADOMED will try to enforce it's requirements more strictly for you on you, unlike us.