On 21 January 2016 at 19:37, Nathaniel Smith <n...@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 _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
