Plugin pyenv4Jeedom

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.

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 ?

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 :wink:

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

voir 4.5

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 :frowning:

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 :wink:

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

1 « J'aime »

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)

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 :wink:

j’ai dû lire trop vite alors :wink:

Merci beaucoup pour ce truc

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 :open_mouth:

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

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

1 « J'aime »

Bonjour,

il y a un début fonctionnel. je fais encore un peu de doc et un frontend approximatif avant de libérer la première bêta.

Un début de doc

A+
Michel

Bonjour,

Une version bêta est disponible sur le market :

La doc est à jour.

Je serais heureux que vous me fassiez des retours.

A+
Michel

Bonjour @Michel_F ,

Tu as du voir que je t’avais taggé sur un autre post :wink:

Mon plugin TTSCast utilise PyEnv de manière autonome, et un utilisateur vient de voir que sur son install où il y a PyEnv4Jeedom installé également, les deux rentrent en conflit :frowning:

Je suis allé regardé ton code d’installation de PyEnv, et j’ai vu que tu déclarais cela au niveau du système (OS), ce qui n’est pas idéal, car cela condamne l’usage de manière autonome de PyEnv ailleurs (aie :frowning: ).

Est-ce qu’il y a une raison pour avoir fait ce choix de le déclarer au niveau système ? Car PyEnv peut fonctionner aussi sans aucune intrusion dans le système hôte et donc de manière totalement autonome :slight_smile: ce qui laisserait le champ libre à d’autres plugins si tel est le besoin :wink:

Sinon, concernant l’usage du plugin en lui-même, perso, je n’avais pas vu cela comme ca (lol, normal tu me diras, on a chacun notre vision, jusque là tout est normal :wink: )

Je m’explique : je voyais le plugin plutôt comme un gestionnaire python, mais toi tu vas bcp plus loin, en proposant également la partie venv, voir plus.

Avais tu une idée ? un souhait derrière ce choix ? car pour moi, le venv doit rester au sein du plugin qui l’appelle pour pouvoir gérer plus finement les packages, l’installation des dépendances, la gestion du check des dépendances, le démarrage et arrêt du démon, etc…

donc je voyais plus le plugin comme l’installeur d’une version de Python (3.11.8 par exemple en ce moment), mais qu’ensuite via une fonction tu retournes le chemin complet de la version de python au plugin qui le demande, et au final, chaque plugin reste dans son scope et garde la maitrise de ses dépendances :slight_smile:

Donc au final, 2 sujets :

  • install niveau système, quid ?
  • que penses-tu des réflexions ci-dessus ?

Au plaisir d’échanger sur ces sujets,
Bonne journée,
TiTidom.

Salut @TiTidom,

je pense que tu as lu ce post et que tu vois ce que j’essaie de faire avec pyenv4Jeedom (p4J). Le plugin MyModbus tout comme d’autres plugins de Noyax37 utilisent (utilisait pour MyModbus) également pyenv en autonome, avec le problème de place que cela génère, d’où l’idée de p4J, pyenv installé une seule fois avec les version de python installées dans un sous-répertoire (ressources/pyenv) et la possibilité de créer des virtualenv dédiés aux plugins qui en ont besoin.

Pour des raisons de facilités pour moi (désolé) j’ai rajouté ce qui allait bien dans .bashrc de root et de www-data, ce que je peux supprimer sans problème.

J’ai déjà expliqué le principe, mais selon moi, chaque plugin n’a pas nécessairement besoin de contenir le virtualenv dont il a besoin. Un plugin, p4J en l’occurrence, peut fournir un virtualenv avec les dépendances demandées. Cette partie peut être externalisée du point de vue du plugin afin de limiter la place utilisée et les ressources, puisque du coup, python 3.11.8 n’est compilé qu’une fois pour ton plugin et MyModbus.

C’est effectivement un point de vue différent.

C’est presque le cas. Le chemin n’est pas retourné, mais il est possible de demander d’exécuter une commande dans le virtualenv préconfiguré avec les dépendances demandées et dédié. Si tu lis la doc (ce que tu as peut-être fait) tu verras que ça permet une certaine simplification de l’appel, puisque tout est géré par p4J.

Je supprime, parce que le plugin n’en a effectivement pas besoin

Ca se défend, mais, comme l’a indiqué Noyax37, et je partage sont point de vue, une même version pourrait n’être installée qu’une fois et plusieurs plugins pourraient s’en servir vie des virtualenv indépendants. Cette fonctionnalité pourrait d’ailleurs, à terme, être intégrée dans le core de Jeedom.
Par eilleurs, tu peux utiliser p4J mais tu n’y es pas obligé.

pyenv4Jeedom n’est est qu’à ses débuts, il faut me pardonner les erreurs et les choix. Comme indiqué dans ce post et un autre précédent lien dans le premier post), j’ai essayé de chercher des infos et de rameuter des dev, mais sans succès. Là au moins, avec une bourde, j’ai réussi à attirer ton attention, c’est un mal pour un bien.

En retirant les lignes des .bashrc, ce sera comme avant pour ton plugin. Encore une fois, tu n’es pas obligé d’utiliser p4J, mais si tu le fais, le gain de place pour certains utilisateur sur des RPI serait notable. Il te faut un virtualenv avec des dépendances particulières, p4J sais faire…

Moi aussi je suis content de pouvoir discuter de ce principe et suis ouvert à toute proposition concrête.

A+
Michel

Bonjour @Michel_F ,

C’est en effet une bonne idée d’avoir en un seul endroit les versions de Python nécessaires :slight_smile: Je ne dis pas qu’il faut que chacun gère ses PyEnv en autonomie (avec les versions de Python qui vont avec) car en effet la place disque n’est pas négligeable et le temps d’install non plus d’ailleurs sur des petites machines :wink: Et puis c’est dommage d’avoir un Python 3.11.8 en trois exemplaires pour 3 plugins différents.

Là on je suis moins favorable, c’est la partie Venv, comme l’a précisé @Mips plus haut dans cette conversation, cela prend quelques lignes à installer et cela permet surtout si besoin de le gérer, d’être libre d’y apporter des spécificités, et de faciliter le troubleshooting avec les utilisateurs au fil des mises à jour des plugins dans le temps.

Un exemple : j’ai vu dans ton code (que j’ai lu rapidement, donc hésite pas à me contredire :stuck_out_tongue: ) que pour la mise à jour d’un Venv, tu fais un delete du venv et tu le réinstalles, or dans bcp de cas, il y a plus simple et surtout moins chronophage (car un venv qui met 25 minutes à installer les dépendances, si c’est juste pour mettre à jour la version de python qui est utilisée dans ce venv, ca fait mal en terme de ressources utilisées :stuck_out_tongue: )

D’autre part, lors de l’installation des dépendances, une fois que tu as lancé l’ordre d’installer le venv, le plugin source (qui demande le venv) n’a plus de contrôle sur ce qui se passe, et plus rien dans ses logs, ca peut être problématique pour troubeshooter une install qui se passe pas bien.

Tout ca pour dire, et cela n’engage que moi :wink: , que j’aime bien maitriser un maximum de pans de mes plugins, y compris les mises à jours, les installs, etc… car par exemple s’il y a un soucis avec un utilisateur d’un plugin, et qu’on commence par lui dire, va voir si p4j est installé, si dans son répertoire il y a un répertoire venv du nom du plugin, où se trouvent les logs d’install des dépendances, etc… ca risque vite de tourner en rond à rejeter la cause sur l’un ou l’autre des plugins sans faire avancer l’histoire.

D’autre part, cela a été évoqué également, comment gérer l’installation des dépendances proprement au niveau « visuel » pour le user ? car si la version de python n’est pas installée par exemple, un plugin va demander à p4j de lancer la compilation (et ca peut aller jusqu’à 30 min d’install), mais pendant ce temps, tu affiches quoi au niveau logs dépendances du plugin qui a demandé l’install ?

Alors soyons clair : j’aime l’idée de ton plugin (même si encore une fois je préfèrerais le voir dans le core), mais c’est par définition un plugin très transverse, qui peut avoir un fort impact sur les autres plugins qui vont l’utiliser, donc il faut qu’il soit hyper « clean » et sur l’usage et sur le code, pour que les devs adhèrent et l’utilisent :slight_smile: (et encore une fois cela n’engage que moi, je ne parle pas au nom des autres dev :wink: )

Je dis ca, car l’usage de pyenv amène des surprises aussi lors des mises à jour notamment, par rapport au owner du répertoire s’il n’est pas le même que celui qui a fait l’install de départ :stuck_out_tongue: (c’est du vécu) etc…

Le venv (virtualenv) est par définition propre à un plugin, et c’est même le coeur d’un plugin dans certains cas, donc je vois pas ce que cela ferait gagner comme place de le mettre dans p4j, car il sera dans tous les cas unique :slight_smile:

Je confirme que même si je n’avais pas encore eu le temps d’écrire ici, j’avais jeté un oeil sur ton plugin et sur sa doc (et au passage, bravo déjà pour le travail accompli ! :slight_smile: )

Je te remercie pour tes actions déjà faites (bravo pour la rapidité :slight_smile: ) et tu as même pris le temps d’aller répondre à Doud, merci :wink:

Pas de soucis, il n’y a que ceux qui ne font rien qui ne peuvent pas de tromper :wink: donc aucun besoin de t’excuser, on est là pour en discuter et avancer tous ensemble :slight_smile: (d’autant plus comme je l’ai dit sur un plugin aussi transverse)

Pour l’instant, je passe par un pyenv autonome, et un venv géré par mon code, car j’avais besoin d’avancer et de stabiliser le plugin sur lequel je bossais, mais à l’avenir si p4j se stabilise et répond au besoin, il sera toujours temps de patcher mes plugins pour l’utiliser :wink:

Donc pour être franc (en général je dis toujours ce que je pense :stuck_out_tongue: ) : vivement la centralisation des versions de python, mais vive l’autonomie des venv lol

Au plaisir,
TiTidom.

1 « J'aime »

bonjour à tous, je pense la même chose que @TiTidom en ce qui concerne les venv associés à un plugin. J’ai essayé de l’exprimer mais sans doute d’une façon moins claire :wink:

Pyenv devrait en effet être intégré au core mais en attendant ce plugin est une très bonne solution. Par contre je n’ai pas assez de compétence pour identifier les effets de bord qu’il peut induire.

++

Salut @TiTidom,

En effet, je vais préciser un truc.
La fonction pyenv::createVirtualenv a un paramètre $_upgrade qui, quand il est mis à true, supprime et recrée le virtualenv, c’est vrai. Cette fonction sert à créer un virtualenv et si celui-ci existe, la fonction lance une exception. Donc pour recréer un virtualenv existant, il faut d’abord le supprimer.

D’un autre coté, il y a la fonction pyenv::runPyenv qui elle permet d’exécuter une commande dans le virtualenv passé en paramètre. Il est donc tout à fait possible de faire tout ce dont on a besoin de faire dans le virtualenv qu’on veut (pip y compris). La fonction pyenv::sourceScript retourne en texte, le script à lancer dans le virtualenv passé en paramètre. Libre à toi d’utiliser cette fonction et d’en modifier le retour.

Là, je ne te suis pas… C’est peut-être la différence entre un venv (terme que tu utilises) et un virtualenv (ce qui est utilisé dans p4J). Un virtualenv est un environnement isolé pour une version python donnée. Donc si tu veux upgrader la version python d’un virtualenv, il faut installer (et donc compiler) la nouvelle version de python, ce qui est de toute façon gourmand en ressources puis créer un virtualenv pour cette version de python.

Excellente remarque ! Il faudrait permettre de rediriger la sortie vers un autre fichier log.
Bonne idée !!

p4J a une page qui liste les virtualenv installés, c’est assez simple de trouver ses billes là-dedans.
Comme il n’y a pas d’équipements (utilisable) ni de commandes, la page de gestion est quasi vide et contient cette liste.

Avec la fonction pyenv::getVirtualenvNames, le plugin peut savoir si la version python nécessaire (et le virtualenv) est installée ou non et prévenir dans les logs que cette version doit être installée.

Dans post-install.sh, je fais un chown www-data:www-data -R ...
J’ai aussi eu des problèmes avec ça…

C’est la raison pour laquelle le nom d’un virtualenv créé par p4J contient en premier l’id du plugin. Par convention, ça veut dire que ce virtualenv est pour ce plugin. Pour un même plugin, il est même possible de créer plusieurs virtualenv avec la même version de python ou pas, il suffit de préciser un autre suffixe.


Je retiens l’idée de la redirection de log, pour le reste, il semblerait que p4J réponde à tous les points, sauf celui de l’emplacement du répertoire qui le contient. Il est cependant possible de faire un lien symbolique. Je vérifierai s’il est possible de modifier l’emplacement d’installation du virtualenv, mais a priori, ça ne me dit rien.

Comme les virtualenv sont de toute façon propres à un plugin (par convention) le fait que ce virtualenv soit stocker ailleurs que sous le répertoire du plugin ne pose pas de problème, sauf peut-être psychologique aux personnes possessives :stuck_out_tongue: . Mais moi, je le vis bien :rofl:

Si p4J était intégré au core, je pense que le fonctionnement serait assez proche du fonctionnement actuel de p4J. Je m’avance peut-être…
Le « problème » de l’emplacement du virtualenv reste ouvert pour moi, mais je pense que la convention de nommage le résout sous forme de compromis à accepter s’il n’est pas possible de préciser où stocker le virtualenv.

Je remarque également qu’il faut plus d’explications sur le fonctionnement et les cas d’utilisation des fonctions de p4J. Mais est-ce que la doc sera lue ? Je ne peux que l’espérer étant donné le temps que ça prend. D’autant plus que cette doc est destinée aux devs qui pourraient avoir besoin de p4J, hors c’est eux (nous) les mieux placés pour savoir qu’une doc ça se lit !

Bien sûr j’essaie de te convaincre que p4J n’est pas si mal que ça au final et qu’il est forcément destiné à évoluer, puisqu’il n’a même pas un mois. Je ne veux pas que tu penses (ni que qui que ce soit le pense d’ailleurs) que c’est LA solution. Chaque dev est encore libre (et heureusement) de faire sa sauce dans son coin comme ça a été le cas jusqu’ici. p4J c’est juste une solution pour économiser des ressources chez les utilisateurs.

A+
Michel