ca serait bien aussi de bloquer une version… que l’existant puisse continuer de fonctionner (vérification avant mise à jour donc) mais oui ça sera une conséquence de tout ca
Bloqué une version c’est quasi impossible. Entre les plugins utilisant le meme packages et les packages qui sont dependant entre eux bloquer une version n’est pas possible.
non, bloquer une version du plugin. pas d’un package.
A d’un plugin, rien a voir avec le sujet ici.
Pour info je viens de rajouter la gestion des npm globaux au systeme.
ok !
d’après le code, je vois qu’on doit donc mettre le nom du paquet dans ce cas là (pas de /)
Oui c’est exactement si ya un / il prend ca comme de l’installation local dans un repertoire basé sur un fichier package.json de npm si installation global
Bonjour @Loic,
je vois dans un des derniers plugins officiels sortis, il y a le type « plugin » dans packages.json.
comment ca fonctionne ? par exemple avec un plugin payant ? est-il activé après installation ?
merci d’avance
Bonjour,
Ca essaye de l’installer, si il est payant et que l’utilisateur ne la pas acheté ca va sortir en erreur.
2 « J'aime »
Bonjour,
Le contenu de packages.json
La vérification des packages détecte bien le manque
Le clic sur Corriger comme l’install des dépendances du plugin installe la dernière version disponible.
Celle avec laquelle on sait que le plugin ne fonctionne pas.
Il faut absolument la 3.7.4.post0 pour que le plugin fonctionne.
Quelle est la syntaxe pour installer une version spécifique d’un module?
Tu ne peux pas ça installe forcément la dernière car sinon c’est ingérable si 2 plugin veulent 2 versions différentes
2 « J'aime »
Je vais être hors sujet mais c’est quoi le problème avec aiohttp?
Pcq je l’utilise pas mal cette lib, elle est assez courante, je ne sais pas ce que ca donnerait de forcer une version d’une lib si répandue 
C’est une rustine temporaire qui a été posée dans ce sujet: KLF 200 ne cesse de redémarrer pour n'importe quelle action!
Pour que le plugin fonctionne, il faut downgrader aiohttp et PyYAML.
1 « J'aime »
Bonjour,
Le système de dépendances est-il compatible avec les venv ?
Non désolé il ne sait pas gérer les venv
Et par rapport à cette install de plug-in, je suppose qu’il prend la version en stable.
Si elle n’existe pas il bascule sur la bêta ?
Ou alors il prend la version qui correspond au plug-in actuel ?
Exemple j’ai installé zwavejs, le core a installé mqtt2 en bêta;
- parce que zwavejs est en bêta ? ou
- parce que mqtt2 n’existait que en bêta ?
Si un plug-in en stable demande d’installer mqtt2 qui n’existe qu’en bêta ça va bloquer ?
Il prend la version stable si elle n’existe pas ça plante (tous les utilisateurs ne sont pas beta testeur donc n’ont pas forcément accès au beta)
Si ya pas de version stable il plante d’où le faite qu’on vous demande d’installer mqtt2 pour zwavejs le temps de la beta, ça ne sera bien sûr plus le cas lors de la stable.
1 « J'aime »
Assez logiquement, on ne devrait pas pouvoir passer en stable un plugin s’il dépend d’un autre qui n’est pas encore lui-même stable.
C’est l’installation des dépendances qui déclenche l’installation des plugins liés ?
Je me suis permis de mettre les exemples ci-dessus dans la doc, pour l’installation des dépendances
2 « J'aime »
Bonne idée, par contre c’est juste un détail mais dans l’exemple de pré install tu pointes vers un fichier qui s’appelle post install:
{
"pre-install" : {
"script" : "plugins/openzwave/resources/post-install.sh"
}