On 9 July 2015 at 05:06, Antoine Pitrou <solip...@pitrou.net> wrote: > On Wed, 08 Jul 2015 13:05:45 -0400 > Tres Seaver <tsea...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
