On Thu, Jan 21, 2016 at 1:31 AM, Nick Coghlan <ncogh...@gmail.com> wrote:
> > I think it's better to start with a small core that we *know* works, > then expand later, rather than trying to make the first iteration too > wide. The "manylinux1" tag itself is versioned (hence the "1" at the > end), so "manylinux2" may simply have *more* libraries defined, rather > than newer ones. > > The key is that we only have one chance to make a good first > impression with binary Linux wheel support on PyPI, and we want that > to be positive for everyone: > > * for publishers, going from "no Linux wheels" to "Linux wheels if you > have few external dependencies beyond glibc" is a big step up (it's > enough for a Cython accelerator module, for example, or a cffi wrapper > around a bundled library) > * for end users, we need to nigh certain that wheels built this way > will *just work* > In general, I see a tension between permissiveness and flexibility in the policy here, with good arguments on both sides. A restrictive policy (like the one we propose) will keep some wheels off PyPI that would work just fine on most Linux boxes. But it will also ensure that fewer broken packages are uploaded. In my opinion, the packaging system we have currently works pretty well. Adopting a loose policy could therefore be experienced as a regression for users who type ``pip install <package>` and receive a broken binary wheel. This is one of the reasons we thought that it would be safest to start small and work incrementally. -Robert
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
