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 . 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.
If you look at the code you will see that the app is able to build the needed python from source (see https://github.com/YunoHost-Apps/homeassistant_ynh/blob/master/scripts/_common.sh). 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.
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.
No. Using Python 3.9 is not a huge deal, I don’t see what top-notch killer feature would be included in 3.10 or 3.11 that would make it worth it.
We use whatever is shipped in stock Debian.
If you get stucked because of limitations to stock Debian, then maybe contribute by joining the campaign to fix apps so they work on Bookworm.
Working on workarounds instead of helping with the actual issue/fix (the Bookworm transition) is only a waste of time, because then we have epic technical issues to debug because one way or another, these kind of magic tweaks always end up making random stuff explose (cf for example people installing stuff in global scope with pip … or anyway installing custom version of Python usually ends up in compiling locally, which takes an epic amount of time, which is not acceptable considering what YunoHost is trying to achieve) and then we (the support team) have to debug the mess
Yeah … please for the love of god stick to regular python venv, python -m venv venv. Anything else seems to be madness…
Note: pyenv is not related to python -m venv
pyenv are scripts to install different Python Interpreter versions on any systems
Yes and no, i think
All of my related projects still work on Python 3.9… Only because of YunoHost
Other projects (homeassistant, tandoor, etc.) need a newer Python.
Migrating more quickly to any new Debian stable version helps in principle, of course.
However, Debian is not super fast, so even fast YunoHost updates won’t solve the problem completely, i think
That’s one of the reasons why some people use Docker or Fatpack etc. But this is a other topic.
The bottom line: We can stay with the current situation: Every package maintainer can stay with the default Python or use his own solution to install a newer one.
Or: We add a helper in the core to install a newer Python.
Or: people can invest energy into the Bullseye->Bookworm transition to help move forward with the general situation for everybody, instead of investing energy into their own specific app needs using their own custom trick and creating cyber-frankensteins
