Bonjour à tous et bravo pour ce boulot que vous mettez à dispo 
Juste une petite question, est ce qu’il est prévu de vérifier que plus aucun plugin n’utilise une version particulière de python lors de la désinstallation d’un plugin afin de libérer l’espace disque si tel est le cas?
Salut,
Excellente question.
En bref: non à date ce n’est pas prévu:
Je m’étais posé la même question et voici quelques éléments qui doivent être pris en comptes pour y répondre selon moi:
/opt[pluginid_remove()] de plugin_info\install.php est exécutée à la désactivation du plugin et on ne peut pas se permettre de désinstaller la version de python de pyenv + casser les dépendances du plugin à chaque désactivationMa conclusion: vu le risque d’impact de le faire et l’impact modéré à léger de ne rien faire, je n’ai pas jugé opportun de pousser à avoir une modif du core pour avoir ce trigger à la désinstallation. J’ai décidé de ne pas le faire.
merci pour cette réponse détaillée
Juse pour expliquer pourquoi je me posais la question c’est surtout pour les anciennes config genre celle que j’avais avant, la smart, où la place de stockage est limitée. Maintenant avec l’Atlas c’est plus large et on se pose moins la question
Autre point, je ne sais pas si c’est possible de l’améliorer mais justement j’avais réactivé ma smart pour essayer la dernière version béta du plugin Brother qui utilise justement tes lib afin de vérifier qu’il n’y avait plus de problème pour installer les dépendances contrairement à la version stable. Bref, lors de la compilation de python 3.11 sur la smart au bout de quelques minutes les dépendances sont passées en rouge et les logs étaient arrêtés à 56% (installation python). J’ai laissé tourné et au bout d’une heure python avait fini d’être compilé et les logs sont repartis et au final les dépendances sont passées au vert. Donc quand la compilation dure longtemps on a l’impression que l’installation a échouée alors qu’elle continue.
Oui ça c’est à fixer par le plugin.
Il faut spécifier dans le info.json le maxdependancyinstalltime (ou une clé du genre) à au moins 1h si on force une version python
Je note, merci 
C’est noté aussi, merci
Je rebondis là-dessus.
J’avais fait un plugin pyenv4Jeedom qui a priori n’est plus utile, mais il avait le charme de :
Tout n’était pas parfait dans le plugin, mais j’avais pensé à ce truc et j’avais une solution. Malheureusement mes échanges avec TiTidom n’ont rien donné. Je ne reproche rien, parce qu’au final les bibliothèques proposées par Mips et lui sont fonctionnelles. Je regrette juste de ne pas du tout avoir été écouté.
Maintenant ce n’est très certainement pas trop tard. Je pourrais, avec l’aide qui veut bien la donner, modifier pyenv4Jeedom de sorte de prendre les installations de pyenv dans /opt en compte. une boucle sur les plugins installés dans leur répertoire puis resources/venv/bin/python --version donne la version installée. Si plus aucun plugin n’utilise cette version, alors on peut autoriser la suppression du plugin. Mais elle doit être demandée manuellement.
Il faut juste que le répertoire resources/venv soit utilisé par tous les plugins utilisant pyenv.lib
edit: pour être sûr que le plugin listé utilise effectivement pyenv.lib, la présence du fichier pyenv.lib doit être vérifié sous resources. Bref il est possible de faire quelque chose, Les solutions ne manquent pas.
Bon là, je suis occupé avec MyModbus, mais après je peux proposer un truc.
Salut,
Là en tant que dev de plugin (pas de pyenv) je suis encore moins d’accord.
Ce n’est pas « sain » qu’un autre plugin/process que je ne contrôle pas agisse sur le contenu de mon plugin. Y a trop de supposition pour que ca fonctionne et comme je disais, loi de murphy:
Si solution, le dev du plugin doit être à l’initiative. Pyenv est un outil mais il ne fait rien tout seul, le dev écrit le code qui lui convient dans son plugin.
C’est principalement pour ça que je ne voulais pas d’une solution « plugin » accessible par l’utilisateur.
Comme j’écrivais juste au dessus, pas la peine de boucler ni de supposer que le répertoire est « venv », on peut rechercher les symlinks
Mais dans les 2 cas on n’est pas à l’abri d’un couac.
Rapport au sujet venv vs virtualenv, la recommandation de debian / python3 sur debian 12 c’est d’installer un venv. j’ai juste suivi ce qui s’imposait de facto comme standard
Au pire les plugins qui n’ont pas été décelés ne fonctionneront plus après suppression manuelle d’une version. L’utilisateur devrait alors faire le lien et réinstaller les dépendances de ces plugins-là.
Mais OK, je ne fais de nouveau rien. Je ne veux rien imposer ni passer pour le canard boiteux qui fait des trucs dans son coin (coin).
Bonjour,
Est-ce qu’on essaie de s’appuyer sur les mêmes versions python entre dev ou chacun fait comme il veut ? Je veux dire : je m’en fiche d’utiliser python 3.11.8. Si la 3.11.4 est déjà installée, roule en 3.11.4. Le fait de demander 3.11 suffit dans le script d’install, je sais, mais est-ce que quelqu’un demande une version spécifique ?
Ou alors on s’en fiche et chacun y va avec sa sauce
A
Michel
mon avis en bref: on s’en fiche
je veux dire: je pense avoir expliqué de long en large les tenants et aboutissants en conseillant de se limiter à une version mineur;
Chacun peut à présent faire un choix éclairé et sait qu’il ne devrait demander une version fix précise que s’il a une excellente raison et pas juste « parce que c’est mieux d’avoir la dernière ».
S’il ne le fait pas… tant pis, plusieurs versions seront installées.
On peut aussi espérer que les probabilités soient avec nous et qu’au pire/max il n’y ai que deux versions mineures différentes installées (puisque les autres plugins vont demander « n’importe quelle version »)
Du coté des probabilités, faut aussi que plusieurs plugins utilisent cette lib sur la box… alors oui il y en a quelques un j’imagine vu les questions ici mais ca reste une goutte d’eau probablement
Je suis en train de modifier un de mes plugins pour intégrer vos libs, merci encore pour ce partage.
Je me pose juste une question, si on change de version de python d’une version à l’autre d’un plugin, doit on supprimer le répertoire venv avant l’application des libs ou la nouvelle version s’installera par dessus celle existante?
pyenv.lib s’en charge, si nécessaire il nettoie le venv et le recréé
aussi bien en upgrade que downgrade d’ailleurs
il n’y a qu’une condition: que le script d’install des dépendances soit exécuté
Super, ça fonctionne bien 
Juste un truc, les lignes wget … pour aller chercher les fichiers sur le github ne fonctionnent pas si on ne met pas en 1ère ligne du fichier install_apt.sh:
#!/bin/bash
Édit: ah bah non maintenant ça fonctionne. Entre temps j’ai re établi les droits, sans doute ça
Attention à ceux qui utiliseront ces libs si vous utilisiez auparavant le fichier packages.json comme moi car il faut absolument gérer sa suppression.
Pour ma part j’ai géré cette suppression par l’ajout de ces lignes dans les fonctions xxx_install et xxx_update du fichier /plugin_info/install.php
function solarman_install() {
$core_version = '1.1.1';
$packagesjson = dirname(__FILE__) . '/packages.json';
if (file_exists($packagesjson)){
unlink($packagesjson);
}
...
}
3 messages ont été scindés en un nouveau sujet : Installation de la lib python3-ftdi1 avec pyenv
Hello, j’ai du faire une petite modification (rien de fou fou) dans mon plugin sur la fonction pythonRequirementsInstalled proposé par Mips car j’ai un pakage python qui une fois installé, contient des majuscules/minuscules. Du coup, j’ai ajouté un strtolower
private static function pythonRequirementsInstalled(string $pythonPath, string $requirementsPath) {
if (!file_exists($pythonPath) || !file_exists($requirementsPath)) {
return false;
}
exec("{$pythonPath} -m pip freeze", $packages_installed);
$packages = join("||", $packages_installed);
exec("cat {$requirementsPath}", $packages_needed);
foreach ($packages_needed as $line) {
if (preg_match('/([^\s]+)[\s]*([>=~]=)[\s]*([\d+\.?]+)$/', $line, $need) === 1) {
if (preg_match('/' . $need[1] . '==([\d+\.?]+)/', strtolower($packages), $install) === 1) {
if ($need[2] == '==' && $need[3] != $install[1]) {
return false;
} elseif (version_compare($need[3], $install[1], '>')) {
return false;
}
} else {
return false;
}
}
}
return true;
}
Voilà juste au cas où vous rencontriez le même cas de figure.
en fait il faut mettre le nom du package dans requirements.txt avec le même format que le package réel.
ton strtolower ne fonctionne que parce que tu as tout en lowercase dans ton fichier requirements.txt.
je pense que le mieux serait de rendre la regex case insensitive en rajoutant /i à la fin (pas encore testé) :
if (preg_match('/' . $need[1] . '==([\d+\.?]+)/i', $packages, $install) === 1) {
Je confirme, ça fonctionne 