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

[Eli Schwartz]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1601 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/arch-general/attachments/20200810/4e6724b8/attachment.sig>