The AppImage is based on Debian Buster, which is intentionally older for glibc reasons, so it runs on older distros. Debian Buster ships python 3.7 so we're already violating our own lower version bound.

If we upgrade this to bullseye, this would put the lower version bound to python 3.9

Alternatively, we could include glibc and other low level system libraries in the AppImage to allow running on older distros, but this is not trivial (AFAIK).

We build our own CPython from source as part of the AppImage build:

The AppImage is based on Debian Buster, which is intentionally older for glibc reasons, so it runs on older distros. Debian Buster ships python 3.7 so we're already violating our own lower version bound.

(in the context of the AppImage)
It does not matter what version of python debian packages in apt, as we build our own python and bundle it in the appimage.
This is in contrast with libc, because that is not getting bundled in the appimage, instead it is expected to be provided by the host system running the appimage.

(see

Does that clear up the potential confusion, or am I missing something? :)

The motivation for building the appimage on an old distro is so that users of older distros can still run the appimage.
Whether users of these old distros are able to run Electrum from source using the distro-provided python is orthogonal.

In fact historically, we originally started distributing appimages when we bumped the min required version of python to 3.6 (which at the time was newer than what debian stable shipped). The main motivation was to provide an alternative way for users of distros with old python to still run Electrum easily.
see https://github.com/spesmilo/electrum-docs/blob/6cdb612d8086aae2d93b47e06886913f1971a026/faq.rst#electrum-requires-recent-python-my-linux-distribution-does-not-yet-have-it-what-now

Does that clear up the potential confusion, or am I missing something? :)

No, it was just me being stupid :) I kinda knew we build our own python, but I had the version pinning for reproducibility in my head.

The code in plugin.py now branches in two places depending on the python version, bumping to 3.10 would allow us to simplify that. Besides, the aionostr package fails our tests with python 3.8, but they pass with 3.9. (its setup.py has python_requires >= 3.8)