Use newer Python than 3.9 ?!?

Beside my different Python based projects, i used Home Assistant

After the update today, i see a warning that Home Asistant >=2023.2 will need Python 3.10 and open Python 3.9 no longer supported for Home Asistant >=2023.2 · Issue #159 · YunoHost-Apps/homeassistant_ynh · GitHub for this.

The Question here is, how to handle this?

I see these options:

Has this topic ever been discussed anywhere?!?

I’m not the biggest fan of docker. But that is one of the the main reason to use it, isn’t it? :wink:
I think using Docker could be done without changing anything in the main system.
It would be interesting to try it out. Has anyone try this in the past? I jsut search for “docker” all projects Search · org:YunoHost-Apps docker · GitHub and found only GitHub - YunoHost-Apps/gollum_ynh: A simple, Git-powered wiki with a sweet API and local frontend, packaged with YunoHost and Docker. and it seems that docker usage was removed in Non-docker version by ketsapiwiq · Pull Request #1 · YunoHost-Apps/gollum_ynh · GitHub

I would also add the option “stick to whatever version is supported until Debian Bookworm”

The whole thing about “installing custom versions of python locally” is a pandora box. As far as I know you basically have to compile python locally, which significantly lengthens up the app’s install time on low-end device such as ARM boards

Docker is another pandora’s box. Sure we can have one app using Docker, but then we’ll have another, and another, and another, and we’ll ultimately end up with a fragmented app ecosystem with one portion using Docker, and the other not, for no specific reason. It doesn’t “change anything on the main system”, but devil is always in the detail :

  • Docker needs iptables rules and it is not clear how this interfere with Yunohost’s firewall.
  • Not to mention I’ve seen people in the past having apt/dpkg being broken because for some reason docker-ce upgrade would crash (because using some apps that were packaged using docker, as you found out - but there was other such as diaporadocker_ynh etc)
  • People say there is supposedly “no resource overhead in using Docker vs. classic install”, but soon enough you will need PHP-FPM process or a mysql/postgresql DB. Except many apps need those too, and having a commong PHP-FPM master process, or a common mysql/postgresql stack reduces the overhead … yet many advantages of Docker reside in having “everything docker”, including the DB, cf the DB volumes which store the actual data, and so on …
  • everything else we don’t know about - as I like to say : install stuff is usually stupidly easy. The real issue is the long-term maintenance and every stupid edge case you don’t know about yet and will only learn about along the way of “stabilization”.

With the said I’m not really “anti-Docker” or whatever … I use docker everyday for other projects and it’s awesome. YunoHost suffers from quite a lot of stability/upgrading issues because of trying to remain somewhat “low tech” with it’s “container-less” approach, such as what we see in the major debian upgrades and lack of guarantees that restoring an app from a backup will work. I would be glad if some project would explore building a Yunohost-like distro using the full power of the docker paradigm. But for it to be successful, it would also have to be really mindful of creating something simple that regular human being can use, something tech-savvy folks forget too quickly about (and even in the YunoHost we tend to loose our focus regularly…). And I expect there would be important challenges into keeping things lightweight enough to run on ARM boards (despite the claim that there’s no overhead using Docker, cf previous note) and hackable for people that know only a little bit of CLI.

Anyway, the other thing at stake in the low-tech vs. high-tech of adminsys is this frenesy to always seek having top-notch-up-to-date softwares and technology, sometimes defended by the argument of “security” (which you could also argue the other way around : you could expect that old, well-known software are safer than brand new stuff), and ultimately this goes a long way into complexifying everything. That goes also with the fact that upstream devs don’t really care about distribution (as in “making it effectively possible and easy for people to use your software”) beyond Docker (which alone is not an acceptable answer for distributing software to non-tech-savvy people). There would be a lot to say about how Debian packaging remained too complex and was not suited for webapp development and deployment and how this triggered the explosion of language-specific package managers with debatable behavior and policies … but I digress :wink:. My point being : Debian Stable is a pretty good baseline, and people can live with a 6-month/1-year old software for some time.

1 Like

If you look at the code you will see that the app is able to build the needed python from source (see It was already the case at the end of life of debian buster to propose a not too old version of home-assistant.
For the time no need to worry about it its just a caution for the version that would be shipped after February.

1 Like

Oh. Interesting! Then there is a solution for the problem. This part of code is usefull for all Python based projects.
Have you take a look to pyenv?

Not deeply… It’s perhaps a better way… I don’t have enough knowledge about the subject to understand what that imply for the whole system and how to manage it.