[Python-Dev] Snap Python for simple distribution across multiple Linux distros

[Nick Coghlan]

On 25 May 2017 at 20:32, Martin Wimpress <martin.wimpress at canonical.com> wrote:
> Hi,
>
> On 23/05/17 17:54, Guido van Rossum wrote:
>>
>> I think the I inevitable conclusion is"thanks, but no thanks."
>
>
> Can I ask why this the inevitable conclusion? The Python Foundation make
> packages for Windows and macOS, why not snaps for Linux?

Mainly because there's no real pay-off to CPython as a project in
lowering barriers to adoption for end users: if someone is running
Linux, they're almost always going to have ready access to completely
usable pre-built Python binaries through their system package manager.

That means that if we were to start publishing our own docker/OCI
images, or our own snaps, or our own FlatPak runtime environment, we'd
be incurring additional ongoing effort without a comparable increase
in the audience we're able to effectively reach.

It also relates to the fact that when it comes to the interminable
packaging format debates in the Linux world, the typical pattern has
been for groups and organisations aiming to promote the use of a
particular package format to use the availability of Python to lower
the barriers to adoption for their particular offering, rather than
the other way around. Some examples:

* Debian takes care of providing deb packages and docker images
* Fedora provides RPMs and docker images
* OpenSUSE provides RPMs (and maybe docker images?)
* the Nix community provide nix packages
* Continuum Analytics provide conda packages
* Heroku take care of providing build packs
* Red Hat provides the RHEL/CentOS and Software Collections RPMs and
docker images
* Docker provide Alpine Linux based docker images
* ActiveState and Enthought provide binaries in a suitable format for
their users
* FreeBSD/NetBSD/OpenBSD also provide their own binaries

With snaps vs docker/OCI and snaps vs FlatPak vs AppImage emerging as
new variations of the longstanding "deb vs RPM vs something else"
arguments, "Here's a source tarball, y'all have fun now" remains the
most sensible publication approach for relatively low level operating
system components like CPython, while the `manylinux` ABI definition
provides "usefully broad" compatibility of pre-built wheel files
across a range of Linux distributions.

Cheers,
Nick.

P.S. Full disclosure: I do work for Red Hat, but I'd still be opposed
to the idea even if the suggestion was to publish our own RPMs or
docker/OCI images

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia