Add a ZIP packaging format for Linux?

[freakboy3742]

Via @abdnh on #1976, on the subject of Linux system packages:

I just found out that AppImage/Flatpak already uses python-build-standalone.

The only way to make this work would be to bundle a python executable as part of the package - and that is the sort of thing that makes Linux distro maintainers very grumpy.

If providing that for system packages is not a good option, what about introducing a zip format? For Anki, that'd actually be our preferred format so we don't have to worry about building system packages. Currently we distribute a zip with some custom install scripts.

[freakboy3742]

The caveats on a ZIP build are so significant I'm not sure it's advisable as a target. The problem is Linux itself, and the fact that "Linux" isn't a sufficient description of a platform.

If you're on Windows or macOS, a binary wheel knows what is available, and that set of binary dependencies is fairly extensive, including everything needed to support a GUI app.

On Linux - you can't guarantee anything. The ManyLinux specification exists as the basis for binary compatibility, but it contains... almost nothing. For example, it's impossible to package a GTK app for Linux, because the GTK base libraries aren't part of the ManyLinux interface. PySide6 does publish binary wheels... by including all of Qt in the wheel - which is why the wheels are 200+MB.

In order for a "zip" packaging format to work, you'd need to enforce --only-binary=:all: when installing wheels - and while that option exists, there's going to be a lot of packages that you can't install. On top of that, you won't be able to package any GTK-based app; and a Qt app won't follow any of the system themes.

While there will be a subset of apps for which that is an acceptable set of compromises, it's a situation where I can see it being added to Briefcase, and then we spend eternity explaining what I've just explained to a novice Linux user who doesn't understand that the underlying problem lies with Linux as a platform.

[Jzhenli]

If build a console app with briefcase for the target platform (ubuntu arm32), if possible to package the app with python-build-standalone? Currently app use the system default python version, but we want to use a newer python version. @freakboy3742

[freakboy3742]

If you're able to enforce -only-binary=:all: for your other dependencies, it would be theoretically possible to build an app that used python-build-standalone.

However, you won't be able to distribute that app as a system package. You'd need to use a custom ZIP-packaging plugin to Briefcase, like the one described below.

[abdnh]

FWIW, I explored bundling Python in system packages and got something working:
https://github.com/abdnh/briefcase/tree/linux-system-embed-python
https://github.com/abdnh/briefcase-linux-system-template/tree/embed-python

Disclaimer: Entirely generated by Claude Opus 4.7 and not reviewed yet, but I got a package that doesn't rely on the system Python (which is my main goal) and worked on Debian 13 and Ubuntu 22.

[freakboy3742]

As an aside - the backends for Briefcase are all pluggable. In the short term, a backend that subclasses the system backend and overrides the packaging step to do zip packaging should be entirely plausible; longer term, we've flagged that we'd like to move all packaging to pluggable backends (see #2706).

Great to hear it meets the "works for me" level - my concern for including this as base functionality for be whether it "works for everyone without any problems in the general case". As I flagged earlier, a Toga app will work on a single Debian version I you use it; but it won't if you move it to a different Debian version, or a different Linux distribution. If your app is PySide base, that should be less of a concern, but it will depend on your other dependencies.

[abdnh]

Thank you! Got something working with a plugin and a template based on the default one: ankitects/anki#4774