Oui, j’aurais du préciser, je ne sais plus si c’était déjà là lors de la première version, mais l’argument --upgrade-deps requière python 3.9
c’est pour ca que si pas spécifié via TARGET_PYTHON_VERSION, c’est la 3.9 qui est installée au minimum
j’avais souvenir que si on demandait une version <3.9 alors il forçait en 3.9 mais manifestement c’est pas le cas
donc concrètement:
passe en min 3.9 (ou ne spécifie rien) et ca va passer
je vais voir pour adapter le script pour qu’il n’installe jamais une version <3.9
target 3.8.5, il t’installe la 3.8.5 (et donc build etc si pas encore installée, peut prendre 1h sur petite config)
target 3.8, il va te mettre à dispo n’importe quel version >=3.8.0 et <3.9.0; donc une 3.8.x
ainsi
si un autre plugin a déjà exigé une 3.8.5, pas besoin de réinstaller (et de nouveau prendre 1h) une 3.8.18 (en admettant que c’est la dernière des 3.8, je n’ai pas vérifié)
si aucune version 3.8 dispo, il installe la dernière dispo (donc 3.8.18 dans cet exemple)
c’est important de garder la minor version car certaines versions de lib ne sont dispo qu’avec certaines minor: lib xxx est dispo en v1.2.4 sur python3.7 mais en 2.5.3 sur python3.11 et la v1.2.4 n’est plus dispo donc si après ton script requiere la 1.2.4 et que je t’ai installé un 3.11 tu vas pas être content (c’est un exemple réel que j’ai eu récemment)
donc si vmt c’est critique pour ton dev alors faut spécifier en target la version y compris avec le fix (3.8.5) sinon c’est mieux de target les minor afin d’optimiser le temps (et l’espace disque) global d’installation (car le script va essayer de rationaliser selon ce qui est déjà installé par les autres plugins)
bon en fait en voulant ajouter le test sur la version 3.9 je me rend compte que le principe que je viens de décrire n’est pas respecté dans le cas où la version installée sur le système est déjà > la target.
Dans ce cas, il n’installe pas une autre version mais utilise la version système.
L’idée était en fait de ne pas faire de downgrade sur les minor en plus de à nouveau ne pas imposer un build long d’une version alors qu’à priori celle qui est là va tourner.
en gros si tu demandes une version 3.11 sur bullseye (ayant 3.9), ne pas installer une 3.12 car ta lib n’est peut-être pas encore compatible mais à l’inverse, si tu demandes une 3.9 sur bookworm et que donc 3.11 est dispo, c’est dommage de downgrade…
bref, ca fera l’objet d’une amélioration si un jour quelqu’un rencontre un blocage la dessus
c’est en théorie possible mais en pratique je n’ai jamais été bloqué par ça et j’ai qd même quelques plugins python donc même si pas statistiquement représentatif, je vais m’en contenter pour l’instant
Juste une question sur le principe en passant : si justement il faut une version antérieure de python à celle du système pour des raisons de version de lib (à la « c’était mieux avant »), comment forcer ? Je n’ai absolument pas le cas, mais on ne sais jamais.
Ce n’est donc pas prévu. Je n’ai pas le cas non plus jusqu’ici.
Généralement les utilisateurs jeedom sont plutôt en retard sur les versions debian
Le jour où le besoin sera là et sera réel, on avisera le question. Par principe je ne développe pas quelque chose pour lequel il n’y a pas de besoin.
Surtout que cette situation n’est pas tenable en réalité, dans ce cas, le plugin devra de toute façon très vite être mis à jour pour être en ligne sur le nouvelle version de la lib.
(c’est un exemple réel que j’ai eu récemment)
