-
-
Notifications
You must be signed in to change notification settings - Fork 46
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
ABI pinning #40
Comments
I don't know enough about Technically I believe even bug fix releases are not guaranteed to be ABI-compatible. I don't know how often ABI changes in bug fix releases; I do see that |
Thanks for the clarification, @rgommers! @conda-forge/core, is this a good candidate case to add to |
Yes I'd think that'd be a fine solution. This will cause rebuild migrations as the ABI moves. |
@seemethere any advice here? |
I got an authoritative answer here: it may be okay for bugfix releases, but there are no guarantees and PyTorch does not have tooling or CI to actually test binary compatibility. So it's better to rebuild all downstream packages which use the C++ API. Downstream packages should be quite light-weight compared to PyTorch itself to build (torchvision is the heaviest one) and there aren't that many. |
Just to confirm, should we be pinning cpu/gpu as well? If somebody builds with CPU support, can they use the GPU builds of pytorch and vice versa? |
Currently, we only pin "general" |
I think explicit is better than implicit here.
PR for discussion: #58 |
It depends who "somebody" is. I assume only libraries which themselves implement CUDA code. For pure Python packages and those which only use a bit of the PyTorch (cpu) C++ API, I don't see a need to force them to have separate CPU and GPU packages. |
@rgommers i tend to agree with you. I think that we can suggest that people depend on the specific |
We have added conda-forge wide pinnings. The discussion on choosing package names has moved to |
What's the recommended approach to pin pytorch when there are dependencies that link directly to the C/C++ libraries? (Example).
According to pytorch/pytorch#28754, there are no ABI guarantees... So, should we build against every released major.minor version like we do with
cudatoolkit
? In that case, should that be submitted toconda-forge-pinning-feedstock
(at least thepin_compatible
kwargs)?The text was updated successfully, but these errors were encountered: