[Distutils] draft PEP: manylinux1

M.-A. Lemburg mal at egenix.com
Sat Jan 23 05:44:36 EST 2016

On 23.01.2016 04:26, Nick Coghlan wrote:
> On 22 January 2016 at 22:07, M.-A. Lemburg <mal at egenix.com> wrote:
>> However, system vendors will often be a lot faster with updates
>> than package authors, simply because it's their business model,
>> so as user you will want to benefit from those updates and
>> not have to rely on the package author to ship new wheel files.
> This is true for the subset of packages monitored by distro security
> response teams, but there's a *lot* of software not currently packaged
> for Linux distros that never will be as more attention is given to the
> "rebuild the world on demand" model that elastic cloud computing and
> fast internet connections enable.
> My fundamental concern is that if a package author publishes a distro
> dependent wheel file, pip attempts to install it, and it doesn't work,
> the reaction for many users is going to be "Python packaging is
> broken", not "the packaging of this particular package is broken".

I think helping the user to identify where the problem
originates is certainly possible.

This can be done in a generic way by e.g. having pip or the wheel
package scan the wheel file for shared libraries using ldd and
finding potentially missing libs.

Or we could define a special package post install entry point which
pip calls to have the wheel itself check the system it was installed
on for missing system packages or any other post install actions
that need to take place before the wheel file can be used, e.g.
setting up initial config files.

> However, moving the "generic linux wheels are ignored by default"
> behaviour to pip-the-client, rather than enforcing it as a restriction
> on PyPI uploads could definitely be a reasonable alternative way of
> addressing that concern.

I don't think that's the right strategy. There are certainly ways
to improve error reporting for Python packaging (see above), but
outright rejecting generic wheels is not a good approach, IMO.

The wheel system is not yet complete, but until it is, using
a "we want to protect the user from failing wheels" approach
is not going to help much, since we're just replacing this
with a "we'll let the user handle failing source installations"
approach instead - with the main reason apparently being that
we want to avoid putting the user blame for failures on PyPI,
pip or wheels.

This ignores that fact that generic wheels have a much
better chance of success than source installations of the same
package on the same system (it's rather unlikely that the user
will have the foo-dev package installed with the corresponding
foo binary package).

Marc-Andre Lemburg

Professional Python Services directly from the Experts (#1, Jan 23 2016)
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> Python Database Interfaces ...           http://products.egenix.com/
>>> Plone/Zope Database Interfaces ...           http://zope.egenix.com/

::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611

More information about the Distutils-SIG mailing list