[Distutils] draft PEP: manylinux1

[Donald Stufft]

> On Jan 22, 2016, at 6:29 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> 
> 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).

I should note, once we have some solution to the fact that "linux, 64bit" is
way too generic of a platform tag for the general case I plan to allow the
current super generic platform tags to be uploaded as well to PyPI. We don't
try to prevent you from ever being able to release a broken package, we just
want to make it reasonable that you can do the right thing. In other words, as
long as the tooling makes it possible to do the right thing, the fact that you
can also generate packaging bugs in your project (as opposed to pip doing the
wrong thing) isn't a problem. So if people want to do something that isn't
manylinux and don't want to claim to be a manylinux wheel, they'll be free to
use the current linux tags as well.

> 
>> 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
> adopted.
> 
> 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.

I think that this could probably just be left up to the individual tools? We
already have to decide between multiple candidate wheels, this is just another
thing to look at.

> 
> Regards,
> 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


-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20160122/0c82ecb6/attachment.sig>