On Mon, Aug 10, 2020, 6:46 PM Filipe Laíns via arch-general < arch-general@xxxxxxxxxxxxx> 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 >
