Plugin pyenv4Jeedom

Michel_F · Février 21, 2024, 8:20

Bonjour,

Suite à l’utilisation de pyenv pour la version bêta de MyModbus, à la lecture de ce post et à une conversation avec Noyax37 qui en aurait besoin, je pense que ce plugin est une solution envisageable et, comme tous les plugins, optionnel (vous n’êtes donc) pas obligé de l’utiliser si vous n’en avez pas besoin ou si vous pensez ne pas en avoir besoin.

Nom et id: pyenv4Jeedom / pyenv
Il permet au plugins y faisant référence d’utiliser une version spécifique de python dans un venv dédié. Du coup plus de problèmes de version de module à gérer qui serait en conflit avec tel ou tel autre plugin. Et la version python utilisée est la même quel que soit la version debian installée sur la machine. Permet également de n’installer pyenv qu’une fois pour plusieurs plugins.
Langages utilisés : php, shell
Pas de démon. Install pyenv dans le répertoire du plugin. Pas de cron (quoi que… ?)
Possède-t-il un panel dédié ? Non
Gratuit
Lien GitHub ou autre site de dépôt (si vous le souhaitez) : GitHub - MrWaloo/pyenv4Jeedom

Pour le moment tout est dans ma tête, mais je fais de belles doc

J’ai en tête un mécanisme pour :

qu’un plugin demande une certaine version
que pyenv4Jeedom lui fournisse les ressources (version de python et venv)
que pyenv4Jeedom sache quels plugin a besoin de quoi
que pyenv4Jeedom purge les versions installées mais plus utilisées

Il faudrait encore trouver le moyen de ne pas inclure toutes les installations au backup parce que c’est inutile. Ce point doit être optionnel en fonction du choix de l’utilisateur.

Mips · Février 21, 2024, 8:26

Salut,

Fonction backupExclude de l’eqLogic qui retourne un array de rep à exclure

exemple:

	public static function backupExclude() {
		return [
			'resources/venv'
		];
	}

Bison · Février 21, 2024, 8:40

Hello,

Si ça marche, c’est une bien belle idée pour faciliter les futures développements sous python sans avoir à bien comprendre les venv.

Bon j’aime pas python alors j’évite mais on sais jamais

Mips · Février 21, 2024, 8:52

je sais que @Michel_F va me dire que personne n’est obligé de l’utiliser mais je ne comprend pas comment ca va être plus simple à utiliser que juste 2-3 lignes à ajouter dans son script d’install pour créer le venv:

apt-get install -y python3 python3-pip python3-dev python3-venv
python3 -m venv $VENV_DIR
$VENV_DIR/bin/python3 -m pip install --upgrade pip wheel
$VENV_DIR/bin/python3 -m pip install -r requirements.txt

si c’est un plugin qui gère ca, il faut déjà (faire) installer le plugin (manuellement par l’utilisateur à partir de debian 12 du coup, on ne pourra pas utiliser le packages.json vu qu’on veut installer des dep python après), activation/configuration etc avant qu’on puisse lancer les dep de son plugin.

Ne serait-il pas plus judicieux d’adapter le core directement (cf. le post cité) en gardant le packages.json comme ajd, ainsi les plugins l’utilisant continueront de fonctionner sans modifs?

Michel_F · Février 21, 2024, 9:03

C’est effectivement pour avoir un venv dédié mais aussi une version spécifique de python.

Avec MyModbus bêta, j’utilise packages.json et un script post-install pour installer les modules python avec pip dans le pyenv installé dans ce même script. Le mécanisme est plutôt simple puisque j’y suis arrivé.

Avec un fichier requirements.txt dans un venv d’une version python spécifique, on peut aussi installer ce dont on a besoin assez simplement. La complexité sera éventuellement dans pyenv4Jeedom, et encore…

Je trouve cette solution ouverte et customisable à souhait.

Mips · Février 21, 2024, 9:20

oui ca c’est la différence, j’avais bien noté.

mais donc pas possible de faire tout ca dans le core? (avec pyenv s’il faut comme tu suggères)
c’est une vrai question, il y a p-e un point bloquant que je n’ai pas compris

Michel_F · Février 21, 2024, 9:37

Ce serait effectivement possible dans le core. Et je pense que ce serait top ! Mais du haut de mes quelques mois d’expérience avec Jeedom et étant donné que je n’ai pas (encore ?) participé au dev du core, je ne me voyais pas proposer un tel changement.

J’ai bien essayé de poser la question un jour, mais maladroitement, et il n’y a pas eu d’engouement.

A part ça, je ne vois pas de point bloquant.

Michel_F · Février 21, 2024, 10:00

On pourrait imaginer que dans packages,json, si on a "pyenv": {"version": '3.11.9'} qui est défini alors les modules pip3 à installer doivent l’être dans python 3.11.9 de pyenv dans un venv nommé comme l’id du plugin, par exemple. Il ne faut pas autoriser de version latest sans quoi tous les venv doivent être actualisés.

Cependant, il y a un mécanisme d’actualisation de pyenv (juste un git fetch ou équivalent) pour récupérer la liste des versions python installables. Il faudrait savoir quand lancer cette actualisation. Dans le plugin, j’aurais mis un bouton pour actualisation manuelle et une instruction pour actualisation demandée par un plugin avant d’installer une version de python.
Mais tout ça peut également être dans le core et ce bouton dans la config de Jeedom, quelque part… ET une mise à jour avant l’installation d’une version de python suffirait, à vrai dire. Sinon c’est pas nécessaire d’actualiser.

J’écris en même temps que je pense, c’est pas forcément ordonné. J’imagine que c’est tout à fait faisable aussi bien dans un plugin que dans le core.

Michel_F · Février 22, 2024, 7:34

Bonjour,

bah du coup je ne sais pas si je peux développer ce plugin ou si ce sera à intégrer dans le core…

Si c’est un plugin, peu importe (ou presque) la version Jeedom installée, ça fonctionnera. Si c’est dans le core ce sera sans doute à partir de la 4.4 qui ne sera stable que dans quelques temps et vers laquelle tout le monde ne va pas migrer tout de suite…
Qui prend la décision ? Si c’est à intégrer dans le core, c’est quelle branche ?

Noyax37 · Février 22, 2024, 7:49

Perso je trouve l’idée géniale mais je n’ai pas assez de compétence pour imaginer les effets induits. Je serai un peu moins précis que @Michel_F dans les install de python, par exemple juste définir 3.9 plutôt que 3.9.5, car on risque vite de se retrouver avec pas mal de version de python installées et sachant que ça prend plus de 500Mo chaque la place occupée sera grandissante. De mes faibles expériences je n’ai pas encore vu de module qui limite uniquement à la 3.7.8 par exemple mais plus à des version minima.

Mes besoins sont pour 2 plugins qui demandes chacun pour des modules nécessaires les version 3.8 et 3.9 mini de python pour pouvoir s’installer. Alors j’ai contourné le pb en téléchargeant ces modules et en les adaptant à la version 3.7 mais à chaque changement de version de ces modules si je veux les intégrer à ces plugins je dois refaire les mêmes bidouilles. Suite à une conversation avec @Michel_F qui a utilisé pyenv j’ai voulu faire la même chose. C’est super, ça fonctionne bien mais j’ai été confronté au problème d’utilisation de l’espace de stockage. Donc un plugin pyenv ou même mieux une utilisation possible au niveau du core serait une belle solution à mes problèmes.

Il y a peut être d’autres possibilités de faire et si c’est le cas je suis preneur de toute suggestion

Mips · Février 22, 2024, 7:49

tu peux toujours développer un plugin
au pire il sera toujours temps de « migrer » le code dans le core

voir 4.5

Mips · Février 22, 2024, 7:56

oui ca je suis bien conscient; c’est buster qui nous bloque, il faut qu’on pousse les utilisateurs sur bullseye;
mais reste le problème des box officielles: smart (surtout) & atlas

Noyax37 · Février 22, 2024, 8:04

oui mais après ça sera python 3.15 qui sera nécessaire et bullseye qui va nous bloquer… euh je m’avance peut être un peu, je ne sais pas si debian 12 va nous bloquer de la même façon pour la version de python mais j’imagine

Michel_F · Février 22, 2024, 11:26

Bien donc, je continue de commencer le dev de ce plugin

Noyax37 · Février 22, 2024, 1:36

Je ne sais pas si tu sais mais on peut demander l’install d’un autre plugin lors que l’installation dans le package.json:

  "plugin": {
  },

Est ce que quelqu’un aurait toutes les options qu’il est possible de mettre dans le package.json? Je retrouve:

apt
pip2
pip3
npm
yarn
composer
plugin
post-install (sous commandes: restart_apache et script)
pre-install (sous commande script)

Michel_F · Février 22, 2024, 2:09

Je le savais, tout est bien documenté avec le plugin-template.

A vrai dire c’est aux dev des plugins qui auront besoin de pyenv de le savoir

Noyax37 · Février 22, 2024, 3:59

j’ai dû lire trop vite alors

Noyax37 · Février 22, 2024, 9:23

Merci beaucoup pour ce truc

TiTidom · Février 25, 2024, 6:05

Bonsoir,

Je m’insère dans cette discussion pour évoquer le cas du plugin TTSCast : Si je veux suivre les versions des librairies que j’utilise pour le démon de ce plugin (python), je vais devoir utiliser dy PyEnv, car les dernières versions imposent l’usage du Python 3.11 (sinon la lib ne s’installe pas), sauf si l’un d’entre vous d’un coup de baguette magique fait passer tous les utilisateurs en Debian 12 (version qui utilise Python 3.11 nativement).

J’ai une version opérationnelle de mon code avec du Python 3.11 sur un Debian 11, sans aucune interaction avec le système et je stocke tout dans le plugin ttscast (pour ne pas risquer de casser un autre plugin qui voudrait utiliser aussi du PyEnv), ca fonctionne bien pour le moment. J’ai exclu ces répertoires des sauvegardes, car ca prend de la place ! (et inutile dans un backup car dans tous les cas, il faut le réinstaller à la restauration…)

Mais plusieurs questions se posent si on est plusieurs à utiliser PyEnv (chacun en autonomie pour l’instant, en attendant de voir si géré par un plugin, ou par le core ?).

Je fais référence à un autre poste où la question était posée :

Pour ma part, j’ai fait le choix de ne pas interagir du tout avec le système, donc j’utilise pas les répertoires par défaut (ni de variables d’environnement), mais je les force au moment de l’install dans le script pour tout stocker dans le répertoire « resources » du plugin.

Concernant un plugin pour gérer des environnements Python : c’est une bonne idée (même si je pense que ce serait encore mieux via le core de proposer la possibilité d’avoir plusieurs version de Python à disposition des plugins, car c’est vraiment un composant proche du système), mais il va falloir voir comme gérer cela, notamment au niveau des chemins à utiliser pour appeler un executable python de telle ou telle version (chemin que j’utilise par exemple dans le script d’install .sh pour créer un « venv »).

Et il faudra aussi gérer le fait qu’à chaque compilation d’un environnement Python, suivant la configuration de l’utilisateur, ca peut prendre une plombe de compiler (jusqu’à 15 min sur un Odroid C2 par exemple, sans optimisation, car sinon ca passe carrément pas, ca plante au bout d’une heure), et que ca utilise 337Mo de données pour un Python 3.11.8 par exemple, sans compter la place qu’il faut au moment de la compilation

Au plaisir d’échanger sur le sujet,
Bonne soirée,
TiTidom.

Michel_F · Février 25, 2024, 7:52

Bonjour,

je fais sans doute presque pareil que toi pour MyModbus version bêta et je connais les problèmes d’environnement liés à l’exécution de script python via pyenv depuis Jeedom.

je proposerais bientôt une version bêta (elle est déjà présente sur le market mais absolument pas fonctionnelle, il ne faut pas encore l’installer !).

je donnerai des nouvelles prochainement

A+
Michel