Je viens d’ajouter en alpha un gestionnaire de packages (apt) qui, à partir d’un fichier json en entrée, regarde les packages manquants et les installent (lors d’un test de consistance ou sur lancement manuel). Vous pouvez le trouver dans la configuration de Jeedom, onglet OS/DB.
Il est aussi compatible avec les plugins (seul le plugin openvpn dans la beta de demain le supportera pour le moment). Lors de l’installation des plugins le core regarde les packages dont à besoin le plugin et lancera automatiquement l’installation de ceux-ci. A ce niveau j’ai pas encore fini toute les cinematiques (en particulier la c’est encore le plugin qui dit s’il lui manque des packages ou non ça devrait être au core de le faire).
L’idée final et de rentre ce gestionnaire de package compatible apt et pip (voir d’autre en fonction du besoin et de la difficulté) pour gérer les dépendances des plugins le plus possible (les scripts de dépendance seront bien sur toujours possibles).
C’est une bonne idée
je viens de tester et il m’en manquait 2 donc j’ai pu corriger
par contre, peut-être voir le message du résultat pour que se soit lisible par tout le monde (peut-être en vert si c’est Ok)
Bonne idée, ça simplifiera les checks de dépendances j’espère.
Envisage tu quelque chose de semblable (ou via ce nouveau système) la gestion de dépendances composer Php par exemple?
Par exemple sur des grosses install les fichiers de la lib guzzlehttp se retrouvent surement 5, 10 fois ou plus… pas super optimal en terme d’espace disque pris
Ca serait top qu’il puisse y avoir un autoload global appartenant au core qui se s’update/rebuild à chaque install/update d’un plugin en tenant compte des nouveaux requirements du plugin (si le plugin a déclaré ce qu’il avait besoin) et qu’au niveau du plugin on n’ait juste à include l’autoload du core
Après je me rend compte que ca c’est un gros morceau à mettre en place, mais comme cela ne peut marcher que si c’est prévu dans le core j’aurais voulu avoir ton avis
Ca serait possible je peux l’ajouter dans la liste mais le soucis c’est que ca oblige a installer composer sur le client faut je vois comment fiabiliser ca au mieux. Mais oui c’est le but la deja je vais essayer de gerer au mieux apt une fois bien fiable je le passe en 3 et 4 puis après j’ajouterais pip et composer si j’y arrive
Pour être sûr de bien avoir compris, ça veut dire que dans l’état du code actuel tu peux par exemple forcer l’installation du paquet python soupsieve dans sa version 1.8 et non pas 2.0 (nécessaire au plugin openenocean sous buster) ?
l’idée ce n’est pas une version spécifique mais plutôt une version maximale, par exemple en fonction de stretch ou Buster.
Je t’invites a bien regarder ce cas de figure :
Looking in indexes: https://pypi.org/simple, https://www.piwheels.org/simple
Collecting beautifulsoup4
Using cached https://files.pythonhosted.org/packages/c5/48/c88b0b390ae1f785942fc83413feb1268a1eb696f343d4d55db735b9bb39/beautifulsoup4-4.8.2-py2-none-any.whl
Collecting soupsieve>=1.2 (from beautifulsoup4)
Using cached https://www.piwheels.org/simple/soupsieve/soupsieve-2.0-py2.py3-none-any.whl
soupsieve requires Python '>=3.5' but the running Python is 2.7.16
