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