[Distutils] draft PEP: manylinux1

Paul Moore p.f.moore at gmail.com
Thu Jan 21 14:58:15 EST 2016


On 21 January 2016 at 19:37, Nathaniel Smith <njs at pobox.com> wrote:
>> Right now, no one can upload Linux wheels, so that a fair
>> setup.
>
> The fairness that I'm more worried about is that right now Windows and OSX
> users get wheels, and Linux users don't. Feature parity across these
> platforms isn't everything, but it's a good start.

100% agreed. I don't use Linux, but as a Windows user, the fact that
Linux users are excluded from using wheels saddens me because it means
that without support for the large base of Linux users we still don't
have a good binary distribution story.

The story isn't perfect on Windows or OSX either. Let's not let a
quest for perfection stand in the way of helping people get stuff
done.

>> Using an approach where every single group first has to write
>> a PEP, get it accepted and have PyPI and pip patched before
>> they can upload wheels to PyPI does not read like a community
>> friendly approach.

The valid Linux tags are defined in a pep, and coded in pip. But
experience has shown that those tags are not a usable solution. Fixing
that *requires* a PEP and a change to pip. There's no way round that.
But equally, there's no reason we can't have more than one PEP/change.
Just because someone has done the work and offered a PEP doesn't
preclude anyone else doing so to. Contrariwise, if Nathaniel's PEP
wasn't around, that wouldn't stop anyone with an alternative proposal
from having to write a PEP.

So I'm not sure what you're saying here. That the PEP process in
general is not community friendly? That writing a PEP that turns out
to be insufficient in one small area is somehow a huge issue for the
community? That the wheel spec should never have been subject to the
PEP process? That we should let people upload wheels with the
insufficiently precise "linux" tag to PyPI and let the users sort out
the resulting mess?

OTOH, if you're suggesting that people might be put off proposing
alternatives to the manylinux suggestion because of the grief
Nathaniel is getting over what is (IMO) a practical, well-researched,
and field tested suggestion, then you're possibly right. But the
easiest way to fix that is to accept that it's a good proposal
(possibly only an initial step, but that's fine) and approve it,
rather than requiring it to be perfect (as opposed to merely
significantly better than what we now have).

FWIW, the proposal has a solid +1 from me.

Paul


More information about the Distutils-SIG mailing list