[Distutils] draft PEP: manylinux1

[Nathaniel Smith]

On Jan 21, 2016 8:53 AM, "M.-A. Lemburg" <mal at egenix.com> wrote:
>
[...]
> And that's the problem: The set is limited to the needs
> of the scientific community and there to the users of
> one or two distributions only.
>
> It doesn't address needs of others that e.g. use Qt or GTK as
> basis for GUIs, people using OpenSSL for networking, people
> using ImageMagick for processing images, or type libs for
> type setting, or sound libs for doing sound processing,
> codec libs for video processing, etc.

I've pointed out several times now that our first test package was Qt
bindings, and Glyph told us last week that this proposal is exactly how the
cryptography package wants to handle their openssl dependency:
https://www.mail-archive.com/distutils-sig@python.org/msg23506.html
So this paragraph is just you making stuff up.

Is manylinux1 the perfect panacea for every package? Probably not. In
particular it's great for popular cross platform packages, because it works
now and means they can basically reuse the work that they're already doing
to make static windows and OSX wheels; it's less optimal for smaller
Linux-specific packages that might prefer to take more than of Linux's
unique package management functionality and only care about targeting one
or two distros.

> The idea to include the needed share libs in the wheel
> goes completely against the idea of relying on a system
> vendor to provide updates and security fixes. In some cases,
> this may be reasonable, but as design approach, it's
> not a good idea.
>
> > [...]
> >> Another detail we have found when external dependencies
> >> is that some platforms use different names for the libraries,
> >> e.g. RedHat has a tendency to use non-standard OpenSSL
> >> library names (/lib64/libssl.so.10 instead of the more
> >> common libssl.so.1.0.0).
> >>
> >>> 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:
> >>
> >> Sure, but if we get the concept wrong, it'll be difficult
> >> to switch later on and since there will always be libs not in the
> >> set, we'll need to address this in some way.
> >
> > There's no lock-in here -- any alternative approach just needs its own
> > platform tag. Pypi and pip can easily support multiple such tags at the
> > same time, if more sophisticated proposals arise in the future. In the
mean
> > time, for packagers targeting manylinux is at least as easy as targeting
> > windows (which also provides very few libraries "for free").
>
> Yes, there's no lock-in, there's lock-out :-)
>
> We'd simply not allow people who have other requirements to
> upload Linux wheels to PyPI and that's not really acceptable.
>
> Right now, no one can upload Linux wheels, so that a fair
> setup.

The fairness that I'm more worried about is that right now Windows and OSX
users get wheels, and Linux users don't. Feature parity across these
platforms isn't everything, but it's a good start.

> Using an approach where every single group first has to write
> a PEP, get it accepted and have PyPI and pip patched before
> they can upload wheels to PyPI does not read like a community
> friendly approach.
>
> I also can't imagine that we really want proliferation of
> "linux" tags for various purposes or even for various
> versions of library catalogs.
>
> What we need is a system that provides a few dimensions
> for various system specific differences (e.g. bitness,
> architecture) and a recommendation for library
> versions of a few very basic libraries to use when
> compiling for those systems.
>
> I believe the PEP is almost there, it just needs to use a
> slightly different concept, since limiting the set of
> allowed libraries does not provide the basis of an open
> system which PyPI/pip/wheels need to be.

Like Nick, I'm still not sure what this "slightly different concept" you
keep referring to is.

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