search

MichaIng / DietPi

Lightweight justice for your single-board computer!
https://dietpi.com/
GNU General Public License v2.0
4.79k stars 494 forks source link

Python versions #7191

Open Mausy5043 opened 3 weeks ago

Mausy5043 commented 3 weeks ago

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:

MichaIng commented 3 weeks ago

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 commented 2 weeks ago

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 commented 2 weeks ago

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:

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.