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

[Daan De Meyer]

I was evaluating whether we could simply avoid pip altogether and get by
with zipapp only as it's quite simple and avoids pip altogether. As Eli
deduced correctly, the big advantage is getting an executable that you put
anywhere and run with sudo without python having trouble finding the
corresponding python module. This would let you put the archive in
~/.local/bin (assuming that is in the PATH) and let you run sudo mkosi
without getting import errors because python can't find the mkosi modules.
To get that working with pip it seems you're forced to write a bash script
that adds the user's site packages directory to PYTHONPATH before invoking
mkosi itself with python which works but feels a bit hacky. I guess if it
didn't have issues python would likely do it by default.

Anyway, thanks for the discussion. For now, we'll support both approaches
so users and distro packagers have the final choice in what they decide to
use.

Daan



On Tue, 11 Aug 2020 at 01:25, karx via arch-general <
arch-general at archlinux.org> wrote:

> 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
>
> >
>