Preliminary manylinux2 support.

[markrwilliams]

Teaches pip how to install manylinux2 wheels. See pypa/manylinux#152, pypa/auditwheel#88.

[pradyunsg]

This'll have to wait till at least manylinux makes the merge.

[ncoghlan]

@pradyunsg I think pip can avoid having to wait for manylinux2010 build support by using a test wheel that's actually just a renamed manylinux1 wheel. As long as the test wheel used doesn't depend on the ncurses 5 ABI, that's a valid thing to do.

[ncoghlan]

Given the removal of ncurses 5 from the ABI requirement, this implication isn't necessarily true: it's possible for a platform to be compatible with manylinux2010 without being compatible with manylinux1.

[njsmith]

In practice pip's heuristics for deciding whether a platform is compatible with manylinux1 and manylinux2010 don't actually do any checking of ncurses. I suppose it's possible for someone to provide a _manylinux module that disables manylinux1 but enables manylinux2010 (though this would be very unusual).

The branch below that just calls is_manylinux2_compatible and is_manylinux1_compatible seems like the simplest approach, and it's obviously correct. In fact I don't even understand how this branch could get hit in the first place...

[ncoghlan]

@njsmith The _manylinux.is_manylinux1_compatible == False override is exactly the case I had in mind. While that's unusual now, and while formally incompatible distros may choose not to set it on the basis of "ncurses dependencies are rare, while manylinux1 wheels are common", I think we want to start out with the position that both variants of Linux platform compatibility should be checked independently.

As for how this branch can be reached, it's only when manylinux2010 is passed in specifically as the platform argument (presumably because the system checking the tags isn't actually a Linux system, or else isn't manylinux compatible).

So I think the best way to start out will be with a strict interpretation of the manylinux2010 compatibility tag, and then treat "Opt-in to accepting manylinux1 wheels when explicitly specifying a manylinux2010 target" as a follow-on feature request.

[ncoghlan]

@wtolson pointed out that the PEP explicitly calls for manylinux1 wheels to be treated as manylinux2010 compatible, even with the ncurses dependency issue: https://www.python.org/dev/peps/pep-0571/#backwards-compatibility-with-manylinux1-wheels

I don't think it's worth going back and amending the PEP at this point, so let's just keep the branch, and add a reference to that part of the PEP in a comment.

[pradyunsg]

@ncoghlan I'm cool with that. I'm not completely familiar with the details here so, I'll defer for the merge to someone else. :)

PS: Thanks for the tracking issue. I was gonna ask "what's the POA" and noticed that you'd created one. ^.^

[ncoghlan]

Just putting a blocking "needs updating to reflect the accepted version of PEP 571" change request on here :)

That should mostly just be the name change to manylinux2010, but there's also the inline comment about the fact that a platform can be manylinux2010 compatible without being manylinux1 compatible, so the two tags should be checked separately rather than assuming one implies the other.

[ncoghlan]

Ah, I forgot I don't actually have commit access on the pip repo - @pradyunsg or @pfmoore, would you mind adding a "requires changes" review to prevent accidental merges?

[pradyunsg]

As @ncoghlan requested.

[dstufft]

FWIW I feel like this is probably a bit of footgun. It feels like the kind of thing that's asking to be a bug once we have a manylinux2018 or something.

[pradyunsg]

Closing in favour of #5410. @markrwilliams if you do want to continue with this, feel free to ask to reopen this PR. :)

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.