-
-
Notifications
You must be signed in to change notification settings - Fork 19
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
Segmentation fault and PyTorch compatibility #47
Comments
We are in fact pinning pytorch, but this is not working intended. |
Ah, I think it's because we didn't rebuild after conda-forge/pytorch-cpu-feedstock#89... |
@adamjstewart for your particular usecase, please install pytorch 1.10 for now
|
We kinda messed up early pinnings with pytorch 1.10. I thought I caught them all, but I guess we need a repo-patch. I am very scared of doing those though, so I thought we would just migrate to 1.11 and get it over with that way. |
Yeah, I think a rebuild for 1.10 and then the migration for 1.11 (very) soon, should be fine. TBH, I'm quite surprised that having an unpinned runtime-requirement keeps the run-export from being added - I would have thought that to be additive (cf. c1664fe). |
Its not that. The pytorch package is a split package and we didn't add it to the right place. Also, the upper bound on setuptools likely messes with the solver. It tries to optimize setuptools, instead of pytorch. |
Solution to issue cannot be found in the documentation.
Issue
If I run
conda install torchvision
, it currently installs PyTorch 1.11.0 (the latest version) and torchvision 0.11.0 (the previous version). These versions are incompatible, and lead to a segmentation fault during import:This is due to a number of missing symbols in the following libraries:
Shouldn't the PyTorch dependency version be pinned according to this table?
Installed packages
Environment info
The text was updated successfully, but these errors were encountered: