Make wheel compatibility tag preferences more important than the build tag

[hexagonrecursion]

Fixes #9565

Example

If linux_x86_64 is preferred over linux_i386 the old behavior was to prefer

simple-1.0-2-py3-abi3-linux_i386.whl over
simple-1.0-1-py3-abi3-linux_x86_64.whl

Now pip prefers

simple-1.0-1-py3-abi3-linux_x86_64.whl over
simple-1.0-2-py3-abi3-linux_i386.whl

[pfmoore]

There's also a few lint issues to be fixed.

[pradyunsg]

It might be worthwhile to think about / investigate if there's folks doing things in a weird way here (and decide if we need a deprecation cycle here).

I don't have any opinions on this, but just flagging this because it feels like a case where we'd create nuanced failures for someone.

[uranusjr]

At least one more test (or fixture) is needed to ensure 1.0-1-py3-abi3-linux_x86_64.whl would be prioritised over 1.0-2-py3-any-none.whl. This is arguably the more meaningful test to this change; the current test would pass without flipping the sort logic, if I understand correctly.

[uranusjr]

I seem to recall there was a research on PyPI wheels and basically nobody is using build tags right now. If that’s correct, anybody doing weird things are doing them in private indexes.

If past experience of how those people react to similar behavioural changes, I’m pessimistic how effective a deprecation cycle would be.

[hexagonrecursion]

It might be worthwhile to think about / investigate if there's folks doing things in a weird way here (and decide if we need a deprecation cycle here).

Should I reclassify this a breaking instead of bugfix?

[hexagonrecursion]

the current test would pass without flipping the sort logic, if I understand correctly.

I believe this is incorrect. I ran the test without the code change and got:

___ TestCandidateEvaluator.test_build_tag_is_less_important_than_other_tags ____

self = <tests.unit.test_finder.TestCandidateEvaluator object at 0x729ce6dbd130>

    def test_build_tag_is_less_important_than_other_tags(self):
        links = [
            InstallationCandidate(
                "simple",
                "1.0",
                Link('simple-1.0-1-py3-abi3-linux_x86_64.whl'),
            ),
            InstallationCandidate(
                "simple",
                '1.0',
                Link('simple-1.0-2-py3-abi3-linux_i386.whl'),
            ),
            InstallationCandidate(
                "simple",
                '1.0',
                Link('simple-1.0.tar.gz'),
            ),
        ]
        valid_tags = [
            Tag('py3', 'abi3', 'linux_x86_64'),
            Tag('py3', 'abi3', 'linux_i386'),
        ]
        evaluator = CandidateEvaluator(
            'my-project', supported_tags=valid_tags, specifier = SpecifierSet(),
        )
        sort_key = evaluator._sort_key
        results = sorted(links, key=sort_key, reverse=True)
        results2 = sorted(reversed(links), key=sort_key, reverse=True)
    
>       assert links == results == results2, results2
E       AssertionError: [<InstallationCandidate('simple', <Version('1.0')>, <Link simple-1.0-2-py3-abi3-linux_i386.whl>)>, <InstallationCandid...mple-1.0-1-py3-abi3-linux_x86_64.whl>)>, <InstallationCandidate('simple', <Version('1.0')>, <Link simple-1.0.tar.gz>)>]
E       assert [<Installatio...1.0.tar.gz>)>] == [<Installatio...1.0.tar.gz>)>]
E         At index 0 diff: <InstallationCandidate('simple', <Version('1.0')>, <Link simple-1.0-1-py3-abi3-linux_x86_64.whl>)> != <InstallationCandidate('simple', <Version('1.0')>, <Link simple-1.0-2-py3-abi3-linux_i386.whl>)>
E         Use -v to get the full diff

tests/unit/test_finder.py:310: AssertionError

[hexagonrecursion]

At least one more test (or fixture) is needed to ensure 1.0-1-py3-abi3-linux_x86_64.whl would be prioritised over 1.0-2-py3-any-none.whl.

done

[pradyunsg]

I'm pretty sure PyPI disallows wheels containing build tags, so this shouldn't affect PyPI-only users.

[hexagonrecursion]

If past experience of how those people react to similar behavioural changes, I’m pessimistic how effective a deprecation cycle would be.

Bias alert: you hear complaints from people who ignored the deprecation until you broke their code but you never hear anything from people who headed your warning and fixed things on their end in time.

[BrownTruck]

Hello!

I am an automated bot and I have noticed that this pull request is not currently able to be merged. If you are able to either merge the master branch into this pull request or rebase this pull request against master then it will be eligible for code review and hopefully merging!

[pradyunsg]

@hexagonrecursion Could you update this PR?

[hexagonrecursion]

@hexagonrecursion Could you update this PR?

Incorporated PR feedback and rebased

[hexagonrecursion]

@pradyunsg you have upvoted my comment:

If past experience of how those people react to similar behavioural changes, I’m pessimistic how effective a deprecation cycle would be.

Bias alert: you hear complaints from people who ignored the deprecation until you broke their code but you never hear anything from people who headed your warning and fixed things on their end in time.

Should I change the news entry from bugfix to breaking ?

[pradyunsg]

Nah, bugfix is fine here.