-
Notifications
You must be signed in to change notification settings - Fork 1k
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
open3d==0.18.0 has no wheels with a matching Python implementation tag #7553
Comments
The |
I can repro. We'll take a look. |
Oh I see. It's because I think the error message is wrong though, I need to look at that. |
Thank you for the quick response. Just out of curiosity, what does |
It's an alias for |
## Summary I think this is just inverted. It means that when we fail in #7553, we show a message for "invalid Python implementation" (since there are some wheels that don't match), but we should be showing "invalid platform", matching the order of operations in our compatibility check. Closes #7553.
## Summary This is a second pass at #7556, which was reverted in #7608 due to a regression in #7606. The behavior is actually correct, but a package (`nmslib`) publishes inconsistent metadata, and the change here happened to cause us to select a wheel with "wrong" metadata. It's arbitrary, but it did cause a regression for folks. Since we're now seeing other issues caused by the wrongness here (and since the reporter in #7606 has since removed the dependency), I'm inclined to ship this fix. Closes #7553. Closes #9283.
A minimal code snippet that reproduces the bug:
Result:
Not sure why uv cannot find it as
open3d-0.18.0-cp310-cp310-manylinux_2_27_x86_64.whl
is inside https://pypi.org/project/open3d/0.18.0/#files.The debug message does not provide much insight.
The current uv version (
uv --version
)The text was updated successfully, but these errors were encountered: