On Fri, Jul 10, 2015 at 12:16 AM, Ionel Cristian Mărieș <cont...@ionelmc.ro> wrote:
> 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. David > > Thanks, > -- Ionel Cristian Mărieș > > On Thu, Jul 9, 2015 at 4:50 PM, Nick Coghlan <ncogh...@gmail.com> wrote: > >> 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 >> > > > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > https://mail.python.org/mailman/listinfo/distutils-sig > >
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
