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