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

Nick Coghlan ncoghlan at gmail.com
Thu Jul 9 15:50:30 CEST 2015

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:


(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

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


Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Distutils-SIG mailing list