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

Vendoring Updates: Nov 2020 (round 2) #9170

Merged
merged 6 commits into from
Nov 29, 2020

Conversation

pradyunsg
Copy link
Member

Fixes #9011
Fixes #9077
Fixes #9138

This has been quite a month.

@pradyunsg pradyunsg added the project: vendored dependency Related to a vendored dependency label Nov 28, 2020
@pradyunsg pradyunsg added this to the 20.3 milestone Nov 28, 2020
@pradyunsg
Copy link
Member Author

Looks like we made a mistake in packaging.tags for MacOS tags. :)

@pradyunsg
Copy link
Member Author

pradyunsg commented Nov 29, 2020

Here's the plan to deal with the failing test here: marking it as xfail right now, getting concensus on the right fix upstream and implementing whatever that fix is in a future release. :)

The behavior that we're breaking here is specifically that anyone specifying intel as their architecture through pip's CLI/configuration/env-vars will no longer get x86_64 and i386 wheels during installation. intel is a universal CPU arch that Python uses to denote binaries that work on both Intel CPU architectures on MacOS. Notably, this does not affect anyone using intel wheels even -- those architectures get detected as x86_64 or i386 and those are correctly handled to be compatible with intel wheels. Anyone affected by this can set their CPU architecture to be whichever on is appropriate for their systems (either x86_64 or i386).

puts on release manager hat

I imagine that there's very few people doing this, so it's OK to mark this as a known degradation in behaviour for right now. It is a significantly smaller problem than binary wheels not working properly for most MacOS Big Sur users. It's OK to get this into pip 20.3 -- but we should make a fix upstream or in our code "soon" for this OR... decide that the multi-arch uses specific-arch thing on MacOS isn't something we wanna support. All that, is post 20.3 though. If we get a fix, that can be a bugfix release of pip 20.3.

takes off release manager hat

Phew. :)

@pradyunsg pradyunsg merged commit b5304f3 into pypa:master Nov 29, 2020
@pradyunsg pradyunsg deleted the vendoring/nov-2020-again branch November 29, 2020 19:17
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Oct 5, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
project: vendored dependency Related to a vendored dependency
Projects
None yet
1 participant