On 8/10/20 4:49 PM, 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.
This is more or less the same as adding a zip file to the PYTHONPATH, and importing from it -- it works, from a python perspective, no different from unzipping the files into site-packages. The difference is it is only available when you run the file (plus special considerations for __main__). As you say, this isn't trying to bundle dependencies. It's not really functionally different from just having all code in one script file. On the other hand, this introduces size overhead for packaging due to multiple layers of compression (and zip is not very good at this anyway), probably doesn't play nice with bytecode generation, and reduces the effectiveness of a nice side effect of scripted languages, which is that users can trivially read the script, edit it, etc. Minor niggles, really. I wouldn't consider it a real blocker, personally. That being said, I'd guess the only specific advantage this has over installing as a PEP 376-style Installed Python Distribution is the fact that a single file can reliably locate itself when invoked with sudo, rather than losing track of a 'pip install --user' installed version with a builtin user-specific sys.path that isn't preserved by sudo. Do they necessarily need to be incompatible? You could have a pip-installable mkosi/ which can be used with 'python3 -m mkosi' due to possessing a __main__.py, but which can *also* be zipapp'ed for portability. It might behave very weirdly in the pip install --user case, but on the other hand Arch users will always use the bleeding-edge package, while Debian customizes their distro python package with an elaborate hack to make "sudo pip install" be officially supported and not touch dpkg-managed files. I'm not positive what guidance to give you beyond "I don't think this violates the packaging guidelines in the slightest, so have no fear on that count". -- Eli Schwartz Bug Wrangler and Trusted User