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

[Ionel Cristian Mărieș]

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?

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

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:
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20150710/0bcd7c62/attachment-0001.html>