Python versions

[Mausy5043]

Creating a feature request

Is your feature request related to a problem? Please describe:

I would like to stay up-to-date with Python and as close to the bleeding edge as sensible

Describe the solution you'd like:

Currently Python v3.11.2 is the default install. v3.11.9 is the latest release.
Please, could you offer a (separate) package for Python v3.12 ?
You could consider to have ID 130 to always install and track the Python version that is in the latest security release cycle (now 3.11.9 by the way) and an additional package that installs and tracks the current bugfix release (now 3.12.4)

Describe alternatives you've considered:

• Installing Python 3.12 from source on the Raspberry Pi is near impossible.

[MichaIng]

At system level, this is not trivial, and not really beneficial to achieve. We install the Python version that is shipped with the respective Debian version: https://packages.debian.org/python3 It is moreless required that it stays like this, because a lot of other APT packages depend on these Python packages, like Fail2Ban, Certbot, and many of the end user software packages we offer install options for. They are incompatible with other Python versions, if you do not keep their versions in sync as well, which would mean again other install sources etc, nothing really suitable for a distribution, but only for well experienced admins, setting up themselves.

What you can do, however is installing https://github.com/pyenv/pyenv, which allows every user to install (compile from source) every Python version for every user individually, into an isolated environment, with again the possibility to setup multiple venv/virtualenv like environments for each Python version etc. Very flexible, and it does not collide with the system's Python. We use it for larger Python software, like Home Assistant and microblog.pub, which drop support for older Python versions relatively soon, and have lots of very specific dependencies (dependency versions), which would be problematic/conflicting to install at system level.

Another approach, if you generally want to run the system at bleeding edge, is to use a Debian Trixie based image: https://dietpi.com/downloads/images/ Debian Trixie is the current "testing" branch/version, with e.g. ships Python 3.12.5. It is somewhat comparable to rolling release distros, like Alpine Linux, i.e. software is kept updated pretty regularly, including larger migration steps for basic libraries. Due to this, one needs to manually update some configs, or switch to newer packages with changed names by times. Bleeding edge certainly means much more responsibility and care, compared to running a stable point release distro version, where the major version of software packages remain static, and hence incompatibilities are ruled out on any package upgrades. But Debian testing is, at least from security and bugs point of view, pretty solid. Packages upgrades are all reviewed for a minimum amount of days before being merged etc. So "testing" does not really fit IMO, but it is more the natural matter of fact that major version upgrades of packages, especially libraries, mean breaking changes, mean the necessity to by times fix configs manually, and incompatibilities between old installed and newly merged packages, during migrations, etc. There is no way around this, for no rolling release distro.

[Mausy5043]

Thanks @MichaIng for the detailed answer. Trixie is a bit too much for my taste and I like DietPi a lot, so would like to stick with DietPi on my Raspberry Pies.
But a package that would allow me to install an additional version of Python would be very welcome. I'll look into pyenv. It sounds promising. Perhaps you could put that on the list of dietpi-software?

[MichaIng]

I like DietPi a lot, so would like to stick with DietPi on my Raspberry Pies.

Ah, DietPi is based on Debian, so that does not exclude each other. We offer DietPi images based on Debian Trixie, for testing, but also for those who like to stay at edge (knowing that certain dietpi-software installations might not work by times, when Debian Trixie/testing goes through some major package version transition).

Perhaps you could put that on the list of dietpi-software?

Yeah though it is not so clear how we should set it up. A common use case it to install it into a non-root user's (or even system service user's) home directory, to run Python software in an unprivileged environment. Based on the software you want to run, you then choose the Python version to be installed, and setup the environment. So there is no reasonable "default" way we could install it. The only way that could somewhat make sense, is to make it interactive, i.e. provide a TUI for the pyenv CLI:

• Ask user to choose the user to install pyenv for.
• Ask the path/directory to install it to.
• Ask the Python version or multiple versions to compile.
• Optionally ask for one or more Python modules to install into each compiled Python version environments.

Ah, and it could be even wanted to have multiple dedicated environments for each Python version.

Currently, we use it as environment to ship certain Python software with, so we know the user wants Home Assistent, and then we download and extract pyenv into the prepared service user's home dir, compile the latest Python version, known to be compatible with Home Assistant, and install HA and dependencies into this environment. So there we know all the variables.

[O-J1]

I like DietPi a lot, so would like to stick with DietPi on my Raspberry Pies.

Ah, DietPi is based on Debian, so that does not exclude each other. We offer DietPi images based on Debian Trixie, for testing, but also for those who like to stay at edge (knowing that certain dietpi-software installations might not work by times, when Debian Trixie/testing goes through some major package version transition).

Perhaps you could put that on the list of dietpi-software?

Yeah though it is not so clear how we should set it up. A common use case it to install it into a non-root user's (or even system service user's) home directory, to run Python software in an unprivileged environment. Based on the software you want to run, you then choose the Python version to be installed, and setup the environment. So there is no reasonable "default" way we could install it. The only way that could somewhat make sense, is to make it interactive, i.e. provide a TUI for the pyenv CLI:

* Ask user to choose the user to install `pyenv` for.

* Ask the path/directory to install it to.

* Ask the Python version or multiple versions to compile.

* Optionally ask for one or more Python modules to install into each compiled Python version environments.

Ah, and it could be even wanted to have multiple dedicated environments for each Python version.

Currently, we use it as environment to ship certain Python software with, so we know the user wants Home Assistent, and then we download and extract pyenv into the prepared service user's home dir, compile the latest Python version, known to be compatible with Home Assistant, and install HA and dependencies into this environment. So there we know all the variables.

Appreciate this might not be the right place but 3.11 is the default right. However I keep getting 3.9.2 installed via dietpi-software 😅 is that intended and if not how can I force it?

[Joulinar]

what application you are going to install?

[O-J1]

what application you are going to install?

Django for my web app that I was going to deploy. I end being able to only install Django 4.12 or so instead of v5 like on my desktop, fiding weird differences and I want to eliminate a large variable between testing on my windows machine and deployment target

[MichaIng]

The system Python version depends on the Debian version. Bullseye ships Python 3.9, Bookworm 3.11. The Debian upgrade can be done quite easily on DietPi: https://dietpi.com/blog/?p=3128#upgrade

And if you need to stay on an older Debian, as said pyenv is one solution to easily install any Python version on any Debian version, without overwriting the system Python instance.