[Distutils] draft PEP: manylinux1

[Nate Coraor]

On Fri, Jan 22, 2016 at 10:26 PM, Nick Coghlan <ncoghlan at gmail.com> 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".
>

This is already broken with source dists if you don't have the appropriate
-dev packages (or a compiler) installed. Some package authors provide more
useful feedback explaining what the problem is and how one might resolve
it, rather than dying on a compiler error due to a missing header, but many
do not.

One solution to this for both source and binary distributions is package
manager awareness in the build/install tools, and to have packages declare
their dependencies in structured metadata. A translational layer would make
this easier on package authors: If they only had to say they depend on
"OpenSSL headers" and that was translated to the correct package for the
OS, this could be relayed to the user at build time ("install these
packages using this command") or the package manager could be directly
invoked, if the user has chosen to allow the build/install tool to do that.

--nate


> 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.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20160129/914a811a/attachment.html>