[Distutils] draft PEP: manylinux1

Nick Coghlan ncoghlan at gmail.com
Fri Jan 22 06:29:23 EST 2016

On 22 January 2016 at 20:48, M.-A. Lemburg <mal at egenix.com> wrote:
> People who rely on Linux distributions want to continue
> to do so and get regular updates for system packages from
> their system vendor. Having wheel files override these
> system packages by including libs directly in the wheel
> silently breaks this expectation, potentially opening
> up the installations for security holes, difficult to
> track bugs and possible version conflicts with already
> loaded versions of the shared libs.

For the time being, these users should either pass the "--no-binary"
option to pip, ask their distro to provide an index of pre-built wheel
files for that distro (once we have the distro-specific wheel tagging
PEP sorted out), or else ask their distro to update system Python
packages in a more timely fashion (or all of the above).

> IMO, that's much worse than having to install additional
> system packages to make a Python wheel work.
> The embedding approach also creates licensing problems,
> since those libs may be under different licenses than the
> package itself. And of course, it increases the size of the
> wheel files, causing more bandwidth to be necessary,
> more disk space to be used for wheel caches, etc.

Then *don't publish manylinux wheel files*. Manylinux is, by design, a
platform+publisher-silo model, very similar to the way smart phone
operating systems work, and the way Windows applications and (I
believe) Mac App Bundles work. It is anti-thetical to the traditional
tightly coupled shared everything model adopted by Linux distributions
(where all the binaries are also generally built by a common central
build system).

There is a different model, which could be tagged as (for example)
"integratedlinux1", which is the one you propose. That wouldn't be
viable from a UX perspective without an external dependency
description system like the one Tennessee proposed in
https://github.com/pypa/interoperability-peps/pull/30, but that
approach requires a lot more development work before it could be

>From the point of view of future-proofing PEP 513 against having such
an alternative available in the future, the main question that would
need to be considered is how tools would decide download priority
between a distro-specific wheel, an integrated linux wheel, and a
linux wheel with bundled dependencies.


Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Distutils-SIG mailing list