On 3 November 2016 at 22:10, Nathaniel Smith
On Nov 3, 2016 1:40 AM, "Nick Coghlan"
wrote:
And then it segfaults because it turns out that your library named <X> is not abi compatible with my library named <X>. Or it would have been if you had the right version, but distros don't agree on how to express version numbers either. (Just think about epochs.) Or we're on Windows, so it's interesting to know that we need a library named <X>, but what are we supposed to do with that information exactly?
Well, we weren't trying to fix the problem with incompatible ABI's: the thoughts that I recall were primarily around getting development header files in place, to permit building (and then caching) local binary wheels. The ports system for example, works very very robustly, even though (it used to) require building everything from scratch. That was my inspiration. The manylinux approach seems better to me for solving the 'install a binary wheel in many places' problem, because of the issues with variance across higher layered libraries you mention :).
Again, I don't want to just be throwing around stop energy -- if people want to tackle these problems then I wish them luck. But I don't think we should be hand waving this as a basically solved problem that just needs a bit of coding, because that also can create stop energy that blocks an honest evaluation of alternative approaches.
+1. ...> dnf/apt/pacman/chocolatey/whatever and make my wheel work everywhere -- and
that this will be an viable alternative to conda.
As a distribution of sources, I think its very viable with the approach above: indeed we do similar things using bindep in OpenStack and that seems to be working out pretty well. -Rob