Is xar limited to Python?

[probonopd]

Is xar limited to Python or could it be used for other types of payloads as well? Could it be used as more generic image format for something like AppImage?

[cooperlees]

We've used it internally for other payloads, e.g. Rust and I've heard talk about JAR like usages. but Python was it's major use case as we've historically used PARS (basically PEXs). https://www.youtube.com/watch?v=56C-0o0zwZ4 - Dan talks about them here.

What do you have in mind to use it for? Extend how AppImage works / use some of the primitives here? Happy to answer any questions.

[probonopd]

An AppImage is essentially a self-mounting squashfs file that has a tiny ELF header that does the mounting using FUSE, and then executes whatever payload (e.g., ELF binaries along with libraries, icons, fonts, images) is stored inside. This has been used to ship rather complex Python applications such as the 3D printing slicing software Ultimaker Cura which is built using PyQt.

The end user just gets one file, sets the executable bit, and executes it. The AppImage mounts itself, executes Cura using the bundled Python and PyQt stored inside the squashfs, and unmounts itself after the application exits.

Advantages of shipping software inside AppImages include:

• Applications packaged as an AppImage can run on many distributions (including Ubuntu, Fedora, openSUSE, CentOS, elementaryOS, Linux Mint, and others)
• One app = one file = super simple for users: just download one AppImage file, make it executable, and run
• No unpacking or installation necessary
• No root needed
• No system libraries changed
• Works out of the box, no installation of runtimes needed
• Optional desktop integration with appimaged
• Optional binary delta updates, e.g., for continuous builds (only download the binary diff) using AppImageUpdate
• Can optionally GPG2-sign your AppImages (inside the file)
• Works on Live ISOs
• Can use the same AppImages when dual-booting multiple distributions
• Can be listed in the AppImageHub central directory of available AppImages
• Can double as a self-extracting compressed archive with the --appimage-extract parameter

Here is an overview of projects that are already distributing upstream-provided, official AppImages.

I am wondering how similar this is to xar, and whether there is potential for collaboration here. Especially as in the AppImage project we are looking into using zstandard, and Python app bundling.

AppImage developers are frequently on #AppImage on irc.freenode.net.

[chipturner]

XAR and AppImage do indeed have some similar use cases and implementation details; however, both evolved independently to solve different problems.

XAR is intended to be a simpler solution mainly for command line tools; it has no opinion or awareness of, say, desktop standards for icons or self-updating. It is not intended to replace security mechanisms supplied by OS level package management.

I suspect something like AppImage could use XARs as the delivery vehicle, but I don't think that adds much to AppImage. Likewise, XARs are pretty simple and the added complexity of AppImage isn't something we'd want to add or replace XARs with.