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

Robert Collins robertc at robertcollins.net
Sun Nov 6 00:40:05 EDT 2016

On 3 November 2016 at 21:40, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On 3 November 2016 at 05:28, Nathaniel Smith <njs at pobox.com> wrote:
>> On Nov 2, 2016 9:52 AM, "Nick Coghlan" <ncoghlan at gmail.com> wrote:
>>> Tennessee Leeuwenberg started a draft PEP for that first part last
>>> year: https://github.com/pypa/interoperability-peps/pull/30/files
>>> dnf/yum, apt, brew, conda, et al all *work around* the current lack of
>>> such a system by asking humans (aka "downstream package maintainers")
>>> to supply the additional information by hand in a platform specific
>>> format.
>> To be fair, though, it's not yet clear whether such a system is actually
>> possible. AFAIK no one has ever managed to reliably translate between
>> different languages that Linux distros use for describing environment
>> constraints, never mind handling the places where they're genuinely
>> irreconcilable (e.g. the way different distro openssl packages have
>> incompatible ABIs), plus other operating systems too.
> The main problem with mapping between Debian/RPM/conda etc in the
> general case is that the dependencies are generally expressed in terms
> of *names* rather than runtime actions, and you also encounter
> problems with different dependency management ecosystems splitting up
> (or aggregating!) different upstream components differently. This
> means you end up with a situation that's more like a lossy transcoding
> between MP3 and OGG Vorbis or vice-versa than it is a pristine
> encoding to either from a losslessly encoded FLAC or WAV file.
> The approach Tennessee and Robert Collins came up with (which still
> sounds sensible to me) is that instead of dependencies on particular
> external components, what we want to be able express is instead a
> range of *actions* that the software is going to take:
> - "I am going to dynamically load a library named <X>"
> - "I am going to execute a subprocess for a command named <Y>"

> And rather than expecting folks to figure that stuff out for
> themselves, you'd use tools like auditwheel and strace to find ways to
> generate it and/or validate it.

I don't think thats what we had proposed though its similar.

My recollection is proposing that dependencies on system components be
expressed as dependencies on the specific files rather than on
abstract names. Packaging systems generally have metadata to map files
to packages - and so a packaging specific driver can map
'libfoo1.2.so' into libfoo-1.2 on Debian, or libfoo1.2 on a slightly
different naming style platform. The use of a tuple (type, relpath)
was to abstract away from different FSH's.

ABI's for libraries are well established and at the control of
upstream, so there's no need for random audit tools :).


More information about the Distutils-SIG mailing list