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

[Filipe Laíns]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <https://lists.archlinux.org/pipermail/arch-general/attachments/20200811/d96af50b/attachment.sig>