Repository navigation
PyTorch utils bringing a very old version of torchvision #18
Description
We want to use SAM for a module, which requires torchvision that is newer than what is brought by PyTorchUtils is installing. Based on torchvision release history, the version automatically installed (0.2.0) is almost a decade old. https://pypi.org/project/torchvision/#history
I am testing with the latest 5.8 stable on Linux
Reacted by Fernando Pérez-García
Activity
fepegar commentedon Jan 27, 2025
This is indeed unexpected.
I just tried on Windows (5.8 stable) and got this output:
So for some reason a recent version is collected first, and an old one afterwards.
I can't reproduce outside of Slicer:
$uv init --python 3.9 ltt $ uv add light-the-torch $ uv run ltt install torchfepegar commentedon Jan 27, 2025
Update: I can reproduce by installing both
torchandtorchvision. I've opened an issue atpmeier commentedon Jan 27, 2025
torchvision==0.2.0is the last version of torchvision that was pure Python and thus installable on any system. Whenever you see this, this is an indication whatever platform you are on, is not supported by the compiled versions. #18 (comment) only speaks of Linux. Which architecture? x86 or arm or something else entirely?jamesobutler commentedon Jan 27, 2025
It appears you are suffering from an issue of pip cache.
Referring to https://github.com/pytorch/vision?tab=readme-ov-file#installation there appears to be a tight coupling of which version of torchvision goes with a specific version of torch. In @fepegar's situation it uses the cached torch to install first which is version 2.5.1, and then it goes to install torchvision using the cached 0.9.1 whl. The version of torchvision is compatible with torch 0.8.x so that is why it ultimately gets downgraded.
If you are using Windows and clear out your pip cache location such as %LOCALAPPDATA%\pip\cache then I would expect it would be successful since it would pull latest torch (2.5.1) and latest torchvision (0.20) which happen to be compatible.
For reference in the torch community:
https://discuss.pytorch.org/t/pytorch-keep-installing-wrong-version/169645
fepegar commentedon Jan 27, 2025
Would using
--no-cache-dirin this extension help avoid this issue?muratmaga commentedon Jan 27, 2025
So there are couple different things going on. This particular Ubuntu system provides Nvidia 535.138 driver version, which supports cuda 12.2. Cuda 12.2 is not listed in Pytorch's support matrix (it lists 11.8, 12.1, 12.4). So while it is not technically suitable, the extension installs 2.51 with cuda 12.4 (as shown in the screenshot above). I am still not sure why it is bringing such an old version of torchvision.
If we change the computation backend from automatic and cu118, correct versions of all libraries is installed (see the screenshot below)
jamesobutler commentedon Jan 27, 2025
Per Slicer/light-the-torch#111 (comment), Table 2 of https://docs.nvidia.com/cuda/cuda-toolkit-release-notes/index.html is what light-the-torch uses where CUDA driver is the only thing important for running pre-compiled binaries and not the CUDA toolkit version. On Linux, CUDA 11.1.x and newer binaries require using driver >=450.80.02 while CUDA 12.x binaries require using driver >=525.60.13. So your driver version is suitable for the Cu124 compute backend for torch.
I suspect this was successful partially due to there not being cached versions of the cu118 whl files on your system allowing for it to pull the latest versions from the web.
jamesobutler commentedon Feb 3, 2025
@muratmaga On Windows with a cleared pip cache (%LOCALAPPDATA%\pip\cache) and a fresh Slicer 5.8.0 install, I installed PyTorch using the automatic computation backend and it appropriately pulled latest PyTorch 2.6.0+cu126 along with compatible TorchVision 0.21.0+cu126.
SlicerPyTorch python console output click here
muratmaga commentedon Feb 3, 2025
That unfortunately is not my experience on a fresh Linux (ubuntu system), with a fresh Slicer (5.8) install:
fepegar commentedon Feb 3, 2025
@muratmaga can you share your console output?
muratmaga commentedon Feb 3, 2025
muratmaga commentedon Feb 3, 2025
While it seems to start installing the correct version of torchvision, this is the error after restarting slicer (hence corrupt install message).
muratmaga commentedon Feb 3, 2025
And when I force 11.8 as requisite, everything works:
jamesobutler commentedon Feb 3, 2025
It appears you got latest PyTorch (2.6.0) and latest Torchvision (0.21.0), however it appears to have retrieved PyTorch 2.6.0+cu124 which is actually the default on Linux, but then got Torchvision 0.21.0+cu126 which is a different compute backend. I suspect this is responsible for the error you observed. On Windows the default PyTorch is actually the CPU version which is different from Linux. Oddly the Linux default is the cu124 package which is not even the latest compute backend which is cu126.
@muratmaga I would expect from a fresh Slicer instance again that it would work if you specify the computation backend of cu126 to encourage it getting PyTorch 2.6.0+cu126. I think using a cu11x package is possible with an Nvidia driver >500, but that version of the driver began support for CUDA 12, so using a cu12x package is probably your better bet if you are going to force a computation backend.
jcfr commentedon Feb 3, 2025
This may be relevant:
_manylinuxmodule Slicer/Slicer#8168muratmaga commentedon Jun 16, 2025
possibly relevant: dalcalab/SlicerMultiverSeg#34
fepegar commentedon Aug 19, 2025
Has anyone found a solution?
lassoan commentedon Aug 20, 2025
I don't think there is an issue in general but there are isolated cases of Python environments messed up by installing some very old version by default and then manually installing pytorch version that is incompatible with the system.
When extensions install PyTorch, they can write their minimum version requirement. If the user installs pytorch manually, he can write version requirement in the
Torch version requirementfield and then clickInstall PyTorch.muratmaga commentedon Aug 20, 2025
This is no longer happening with the latest preview versions, so I stopped chasing it.
fepegar commentedon Aug 20, 2025
Reopening as unfortunately this happens with today's preview version on my Apple M2.
fepegar commentedon Aug 20, 2025
Something I've noticed is that in Slicer I get the former, while I get the latter when installingtorch==2.2.2withlttfrom my terminal. The version oflight-the-torchis 0.8.0 in both environments. Maybe @jcfr knows why this might be?Never mind. I guess Slicer’s Python is Intel (x86_64 under Rosetta), so pip picks the Intel wheel.
fepegar commentedon Aug 20, 2025
I've done some LLM digging and it seems that
@pmeier, does
lttforce to download from the PyTorch index? Could the problem be related to that?jamesobutler commentedon Aug 20, 2025
Reviewing https://download.pytorch.org/whl/torchvision/ there are 55 different whls when searching for 0.17.2.
Including a macOS arm whl though of course no CUDA whl for macOS arm since they don’t have Nvidia GPUs:
https://download.pytorch.org/whl/cpu/torchvision-0.17.2-cp312-cp312-macosx_11_0_arm64.whl#sha256=9c3acbebbe379af112b62b535820174277b1f3eed30df264a4e458d58ee4e5b2
and the intel variant:
https://download.pytorch.org/whl/cpu/torchvision-0.17.2-cp312-cp312-macosx_10_13_x86_64.whl#sha256=14fd1d4a033c325bdba2d03a69c3450cab6d3a625f85cc375781d9237ca5d04d
@fepegar See https://github.com/Slicer/light-the-torch?tab=readme-ov-file#is-it-safe about when the PyTorch index is used to get the whls. It pulls from PyPI only if a third party dependency has been pinned.
fepegar commentedon Aug 21, 2025
Thanks for checking, @jamesobutler. I clearly shouldn't have trusted the bot.
But I guess we still don't know why
lttis installing torchvision 0.2.0.