Skip to content
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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

charliermarsh
Copy link
Member

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.

@charliermarsh charliermarsh added the bug Something isn't working label Nov 21, 2024
Copy link
Member

@zanieb zanieb left a 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?

@charliermarsh
Copy link
Member Author

We can change that, but why hesitant? The current behavior is legitimately incorrect — it treats less compatible wheels as more compatible.

@zanieb
Copy link
Member

zanieb commented Nov 22, 2024

Perhaps I'm not following. I'm going off the title:

invalid platform as more compatible than invalid Python

This sounds like we prefer an invalid platform over an invalid Python version — I don't see one of those as more-correct?

@charliermarsh
Copy link
Member Author

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 no wheels with a matching Python implementation tag if the "highest priority" tag is IncompatibleTag::Python, because we're demonstrating that the best wheel we could find uses a different Python implementation. But that's not true -- there are wheels with matching Python implementations, we just treated them as "lower priority" by accident.

@charliermarsh
Copy link
Member Author

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.

@zanieb
Copy link
Member

zanieb commented Nov 22, 2024

Thanks for explaining! Makes sense to me then.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
2 participants