[arch-general] Pros/Cons of Python zipapp packaging

[karx]

On Mon, Aug 10, 2020, 6:46 PM Filipe Laíns via arch-general <
arch-general at archlinux.org> wrote:

> On Mon, 2020-08-10 at 21:49 +0100, Daan De Meyer via arch-general wrote:
> > Hi,
> >
> > We've been discussing the distribution mechanism for mkosi (
> > https://github.com/systemd/mkosi) and one of the ideas is using Python
> > zipapp (https://docs.python.org/3/library/zipapp.html) to allow us to
> split
> > mkosi up into multiple files for easier development without complicating
> > the packaging process. zipapp takes all source files in a directory and
> > bundles them up into a single executable python zip archive so after
> > building the zip you can simply call ./mkosi to run mkosi and can put it
> > anywhere in the PATH to simply run mkosi wherever you want. Are there any
> > issues with this approach from a distro packaging perspective? Zipapp
> > doesn't bundle a specific python version (uses system python and system
> > python stdlib) and we don't intend on bundling any dependencies in the
> > zipapp. I don't think I've ever seen a python application packaged this
> way
> > which is why I'm asking.
> >
> > Cheers,
> >
> > Daan
>
> Hi Daan,
>
> This approach works, although I am not a fan. Are there any reasons for
> you to want to do it this way? Which problem are you trying to solve?
>
> Python packaging is pretty standardized and I would say that most
> likely all the problem you will ever find have been solved already. Why
> not adopt the usual approach?
>
> I do not think this packaging method it would be an issue from a distro
> POV, unless some distro specifically has a guideline against this kind
> of approach, but it might be an issue for Python standalone packaging.
> It is something that can be worked around, but definitely troublesome.
>
> If you want to support this distribution mechanism *in addition* to the
> standard Python packaging, that would be okay. But a distro like arch
> would most probably package it the normal way.
>
> In which case I would ask, who is the user for this? Maybe just as
> standalone? That would make some sense, but given the Python ecosystem
> has decent tooling nowadays, as an upstream I would probably just tell
> users to pip/pipx install mkosi.
>
> I would say that in spirit it goes against the FHS[1], but that is a
> very opinionated and subjective take from my part. Feel free to ignore.
>
> [1] https://refspecs.linuxfoundation.org/FHS_3.0/fhs.html
>
> Cheers,
> Filipe Laíns
>

It looks like he wants to make an executable, instead of a module that you
import or install

Yash

>