[Distutils] Current Python packaging status (from my point of view)

[Robert Collins]

On 3 November 2016 at 22:10, Nathaniel Smith <njs at pobox.com> wrote:
> On Nov 3, 2016 1:40 AM, "Nick Coghlan" <ncoghlan at gmail.com> 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