[Distutils] draft PEP: manylinux1

Robert McGibbon rmcgibbo at gmail.com
Thu Jan 21 04:57:50 EST 2016

On Thu, Jan 21, 2016 at 1:31 AM, Nick Coghlan <ncoghlan at 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
here, with good arguments on both sides. A restrictive policy (like the one
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

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20160121/ef902724/attachment.html>

More information about the Distutils-SIG mailing list