[Distutils] 400 Client Error: Binary wheel for an unsupported platform

David Cournapeau cournape at gmail.com
Fri Jul 10 09:00:14 CEST 2015

On Fri, Jul 10, 2015 at 12:16 AM, Ionel Cristian Mărieș <contact at ionelmc.ro>

> Would be quite useful to see some references and details about the vague
> issues being mentioned in the thread. It would help a lot the less versed
> engineers (like me) understand the issues at hand (and hopefully reduce the
> amount of disagreement overall).
> For example, for me it's not clear what's wrong with Antoine's proposal
> (compile on Centos 5) - it seemed quite sensible approach to produce a
> reasonably compatible binary.
> Some issues with kernel ABI have been mentioned - can anyone point me to
> some resources describing the possible problems? Is it correct to assume
> that it's about using vendor-specific kernel api?

No, it is about some python packages depending directly or indirectly on
kernel features not available in the kernel on centos 5. For example, you
can't build subprocess32 (https://pypi.python.org/pypi/subprocess32/) on
centos 5 kernels.

> Also, what does Conda do to solve the binary compatibility issues and
> distutils or pip could never ever do (or implement)?

They do what almost everybody distributing large applications on Linux do :
they "ship the world". Any large binary python distribution provider does
the same here: except for low level X11/glibc libraries, everything else is
bundled as part of the distribution.

So no magic, just lots of maintenance work.


> Thanks,
> -- Ionel Cristian Mărieș
> On Thu, Jul 9, 2015 at 4:50 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> On 9 July 2015 at 05:06, Antoine Pitrou <solipsis at pitrou.net> wrote:
>> > On Wed, 08 Jul 2015 13:05:45 -0400
>> > Tres Seaver <tseaver at palladion.com> wrote:
>> >> Hash: SHA1
>> >>
>> >> On 07/08/2015 07:10 AM, Antoine Pitrou wrote:
>> >>
>> >> > Seriously, how this is even supposed to be relevant? The whole point
>> >> > is to produce best-effort packages that work on still-supported
>> >> > mainstream distros, not any arbitrary "Linux" setup.
>> >>
>> >> I'm arguing that allowing PyPI uploads of binary wheels for Linux will
>> be
>> >> actively harmful.
>> >
>> > There is no point in reinstating an argument that has already been made
>> > and discussed in the other subthread (of course, you would have to read
>> > it first to know that).
>> Steady on folks - prebuilt binary software distribution is *really*,
>> *really*, hard, and we're not going to magically solve problems in a
>> couple of days that have eluded Linux distribution vendors for over a
>> decade. Yes, it's annoying, yes, it's frustrating, but sniping at each
>> other when we point out the many and varied reasons it's hard won't
>> help us to improve the experience for Python users.
>> The key is remembering that now matter how broken you think prebuilt
>> binary software distribution might be, it's actually worse. And
>> channeling Hofstadter's Law: this principle remains true, even when
>> you attempt to take this principle into account :)
>> If you look at various prebuilt binary ecosystems to date, there's
>> either a central authority defining the ABI to link against:
>> - CPython on Windows
>> - CPython on Mac OS X
>> - Linux distributions with centralised package review and build systems
>> - conda
>> - nix
>> - MS Visual Studio
>> - XCode
>> - Google Play
>> - Apple App Store
>> Or else a relatively tightly controlled isolation layer between the
>> application code and the host system:
>> - JVM
>> - .NET CLR
>> (even Linux containers can still hit the kernel ABI compatibility
>> issues mentioned elsewhere in the thread)
>> As Donald notes, I think we're now in a good position to start making
>> progress here, but the first step is going to be finding a way to
>> ensure that *by default*, pip on Linux ignores wheel files published
>> on PyPI, and requires that they be *whitelisted* in some fashion
>> (whether individually or categorically). That way, we know we're not
>> going to make the default user experience on Linux *worse* than the
>> status quo while we're still experimenting with how we want the
>> publication side of things to work. Debugging build time API
>> compatibility errors can be hard enough, debugging runtime A*B*I
>> compatibility errors is a nightmare even for seasoned support
>> engineers.
>> It seems to me that one possible way to do that might be to change
>> PyPI from whitelisting Windows and Mac OS X (as I believe it does now)
>> to instead blacklisting all the other currently possible results from
>> distutils.util.get_platform().
>> 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
> _______________________________________________
> 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/20150710/cff28b91/attachment-0001.html>

More information about the Distutils-SIG mailing list