Allow apps packaged as native Linux system packages to use a non-default Python

[rmartin16]

What is the problem or limitation you are having?

Currently, Briefcase enforces that apps packaged as native Linux system packages target the default Python for the distro. For instance, Ubuntu 22.04 symlinks Python 3.10 from /usr/bin/python3. However, most distros now allow side-by-side Python installations. So, on Ubuntu 22.04, Python3.11 can be installed; however, Briefcase's native Linux system packages cannot target non-default Python versions.

Describe the solution you'd like

Add support to target non-default Python versions when packaging native Linux system packages.

Describe alternatives you've considered

Status quo.

Additional context

No response

[freakboy3742]

Agreed this would be desirable, provided the upstream provides an easy way to get these "non default" Pythons as part of system packaging. On Ubuntu, that means you need to have a Deadsnakes PPA available - but you can't specify installing a PPA as a dependency of a package (as far as I know), so an app packaged based on a Deadsnakes Python is usable, but requires additional work on the part of the user. I'm not as familiar with the situation on Fedora/Redhat.

That said, I guess we could make this a buildtime warning - if the system provides a non-default Python version, allow it to be used; but warn that the resulting package won't necessarily be as immediately usable, so they're going to need to educate users on how to add a PPA (or whatever).

[rmartin16]

I was partly prompted to create this from this Python Discourse discussion. Detailed there is the current state of Python availability by Linux distributors.

In short, some distros (like Fedora) provide access to all non-EOL Pythons; but it seems most distros provide access to, at least, two Pythons. For instance, Ubuntu 22.04 provides Python 3.10 and 3.11 without user-added PPAs.

❯ docker run --rm -it ubuntu:22.04 bash -c 'apt update && apt install python3 python3.11'
Get:1 http://security.ubuntu.com/ubuntu jammy-security InRelease [129 kB]
[...]
Get:18 http://archive.ubuntu.com/ubuntu jammy-backports/universe amd64 Packages [33.7 kB]
Fetched 33.8 MB in 2s (16.1 MB/s)                            
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
5 packages can be upgraded. Run 'apt list --upgradable' to see them.
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
  libexpat1 libmpdec3 libpython3-stdlib libpython3.10-minimal libpython3.10-stdlib libpython3.11-minimal libpython3.11-stdlib libreadline8 libsqlite3-0 media-types python3-minimal python3.10
  python3.10-minimal python3.11-minimal readline-common
Suggested packages:
  python3-doc python3-tk python3-venv python3.10-venv python3.10-doc binutils binfmt-support python3.11-venv python3.11-doc readline-doc
The following NEW packages will be installed:
  libexpat1 libmpdec3 libpython3-stdlib libpython3.10-minimal libpython3.10-stdlib libpython3.11-minimal libpython3.11-stdlib libreadline8 libsqlite3-0 media-types python3 python3-minimal
  python3.10 python3.10-minimal python3.11 python3.11-minimal readline-common
0 upgraded, 17 newly installed, 0 to remove and 5 not upgraded.
Need to get 12.1 MB of archives.
After this operation, 44.9 MB of additional disk space will be used.
Do you want to continue? [Y/n] 

[freakboy3742]

Oof... that's a pretty damning analysis of the Debian-alikes...

I agree it makes sense to be able to use any Python that is available as a system package. On Debian/Ubuntu, we might want to issue a warning if we detect the Python version in use has come from Deadsnakes. We probably also want to retain the checks to make sure that the installed version is in the "system" folder, not a local source/pyenv/Conda install; but otherwise, I don't see any reason we should restrict the version to just "what is the default python3" on a platform.

[rmartin16]

On Debian/Ubuntu, we might want to issue a warning if we detect the Python version in use has come from Deadsnakes. We probably also want to retain the checks to make sure that the installed version is in the "system" folder, not a local source/pyenv/Conda install

Coming back to this....currently, Briefcase does not care if the Python being used to run Briefcase is not a Python installed by the system itself; Briefcase only verifies that the version of Python running Briefcase is the same as the version of the default system Python. I believe this status quo should remain. I am not sure I see benefits from requiring users to use a system Python to run Briefcase.

[freakboy3742]

Broadly speaking, I agree that we should be as liberal as possible in accepting Python versions.

As for reasons why me might restrict - I seem to recall there are some complications if you use a conda-installed or pyenv-installed version of Python instead of the system package. However, it's been a while since I've tried, so my memory might be failing.