-
Notifications
You must be signed in to change notification settings - Fork 790
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
Treat invalid platform as more compatible than invalid Python #9339
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm still sort of hesitant.
One of the linked issues comes from selecting Python 2 wheels? I feel like we should never read metadata from those?
We can change that, but why hesitant? The current behavior is legitimately incorrect — it treats less compatible wheels as more compatible. |
Perhaps I'm not following. I'm going off the title:
This sounds like we prefer an invalid platform over an invalid Python version — I don't see one of those as more-correct? |
I think the PR title is kind of bad (I copied it over from the previous PR). My understanding of what's happening is that, at present, if we have two wheels with incompatible tags, we treat the wheel the wheel with "less compatible" tags as "higher priority" (which is wrong). Later, in error reporting, we say |
Basically: I think everywhere else we actually do encode that mismatching platform tag is more compatible than mismatching Python implementation or ABI: #[derive(Debug, Eq, Ord, PartialEq, PartialOrd, Clone)]
pub enum IncompatibleTag {
/// The tag is invalid and cannot be used.
Invalid,
/// The Python implementation tag is incompatible.
Python,
/// The ABI tag is incompatible.
Abi,
/// The Python version component of the ABI tag is incompatible with `requires-python`.
AbiPythonVersion,
/// The platform tag is incompatible.
Platform,
} So the system assumes that in various places. Right now, we would actually actively prioritize Python 2 wheels over Python 3 wheels. |
Thanks for explaining! Makes sense to me then. |
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.