Introduction Jeedom 4.2 : installation de dépendance

je ne comprends pas trop là ? que veux-tu dire par « comment c’est lancé » ? ca veut dire qu’on doit demander aux utilisateurs comment ils ont lancé les dépendances avant de lui demander de nous sortir 3 logs ?
on peut en parler dans un autre sujet (peut-etre pas l’endroit) mais ca serait pas intéressant de rediriger (ou copier) ces logs dans l’ancien pluginID_dep ou pluginID_update comme avant ?

je comprends bien pour la partie pre-post mais pour les packages ? on verra au fur et à mesure je suppose, mais je vais attendre quand même un peu qu’on ait des exemples un peu plus complexes que sonos ou monitoring2 ou camera ou openvpn ou gsh (qui consistent tous en quelques packages apt et au mieux un restart d’apache et nodejs et un package.json pour gsh)

Par la mailing list dev qui sert à ca.
Et désolé d’insister mais avec un peu plus d’infos pour que chacun puisse le mettre en place dans ses plugins, meme si c’est pas finalisé, que ca aide justement à le finaliser.
Un mini tuto avec par exemple :

  • les mots clefs pris en charge (apt, node, pip mais aussi post-install que je vois dans sonos par exemple)
  • est-ce qu’il faut garder le paramétrage hasdependency dans info.json
  • peut-on enlever serainement les fonctions dependancy check et install de la classe si on a bien tout de couvert par packages.json

Là je vais faire les tests, mais ca aiderait que ca soit plus explicite
Pour info, entre info.json et packages.json, ca gagnerait a ce que les 2 soient au singulier ou au pluriel, mais pas différents

on peut en parler dans un autre sujet (peut-etre pas l’endroit) mais ca serait pas intéressant de rediriger (ou copier) ces logs dans l’ancien pluginID_dep ou pluginID_update comme avant ?

Ben c’est exactement ce qui est fait et ce que je dis… Tout est redirigé vers un fichier ayant le nom du plugin de mémoire c’est pluginId_packages ou un truc du genre. Et non ya rien a demandé a l’utilisateur jeedom lance toujours l’installation des packages comme avant, juste tu n’as plus a faire les fonctions d’installation ou de tests si tout est ok.

La seule différence c’est si c’est lancer depuis la console de gestion des packages, la c’est une log (packages il me semble) et ca ne prend pas en compte les pre et les post. Mais ca ne change rien pour vous vu que pour les plugins c’est gerer comme avant.

je comprends bien pour la partie pre-post mais pour les packages ? on verra au fur et à mesure je suppose, mais je vais attendre quand même un peu qu’on ait des exemples un peu plus complexes que sonos ou monitoring2 ou camera ou openvpn ou gsh (qui consistent tous en quelques packages apt et au mieux un restart d’apache et nodejs et un package.json pour gsh)

Je n’ai rien de plus complet désolé.

Pour rappel, il y avait deux posts dans la section dev dans lesquels on en parlait, il y a moyen de trouver qlq info là aussi.
Loic y parlait d’une doc qui va arriver aussi je suppose.

Moi ce qui m’intéresserait aussi c’est de voir comment on gère les versions, si j’ai bien compris il y a moyen de demander une version minimum et si la version présent actuellement est plus ancienne il force l’upgrade, correcte?
Mais donc pas possible d’avoir une version spécifique comme c’est géré sous python? par exemple d’avoir une version 2.x de la lib (qu’importe les sous-versions) mais pas une 3 ou une 1.

exemple de ce que j’ai fait jusqu’ici :

{
	"pre-install": {
		"script":"plugins/homebridge/resources/pre-install.sh"
	},
    "apt": {
        "build-essential": {},
        "avahi-daemon": {},
        "lsb-release": {},
        "avahi-discover": {},
        "avahi-utils": {},
        "libnss-mdns": {},
        "libavahi-compat-libdnssd-dev": {},
        "dialog": {},
        "apt-utils": {},
        "git": {},
        "php-gmp": {
            "alternative": ["/php(.*?)-gmp/"]
        },
		"nodejs": {}
    },
	"npm": {
		"homebridge-camera-ffmpeg@latest": {"reinstall":true,"unsafe-perm":true},
		"homebridge-alexa@latest": {"reinstall":true,"unsafe-perm":true},
		"bonjour@3.5.0": {"reinstall":true,"unsafe-perm":true},
		"homebridge-gsh@2.2.0": {"reinstall":true,"unsafe-perm":true},
		"homebridge-config-ui-x@latest": {"reinstall":true,"unsafe-perm":true},
		"plugins/homebridge/resources": {},
		"plugins/homebridge/resources/node_modules/homebridge-jeedom/": {}
	},
    "post-install": {
		"restart_apache":true,
		"script":"plugins/homebridge/resources/post-install.sh"
	}
}

mais j’ai encore des éléments que je sais pas ou ni comment placer… est-on certain que les packages s’installent dans l’ordre dans un même type ?

J’ai un exemple différent ici :
plugin-tplinksms/packages.json at beta · jeedom/plugin-tplinksms (github.com)

Et comme le dit @Mips, l’annonce de l’année dernière (janvier 2021) faite aux devs pour qu’ils se préparent :wink:
Gestion de packages V4.2 - Salon des Développeurs / Core V4 (dev) - Communauté Jeedom

Par la mailing list dev qui sert à ca.

Désolé je ne la connais pas celle la et je n’ai de toute façon ni les droits ni l’accès a l’outils permettant l’envoi de mail en masse. Et même si j’avais tous ce qu’il faut je n’aime pas cette méthode de mail, avec moi c’est le community ou le blog et rien d’autre.

  • les mots clef sont dans l’article
  • oui il faut le laisser vu que j’ai pas dit qu’on pouvait l’enlever
  • oui ou non c’est comme tu le sens, en les supprimant tu perd la compatibilité avec les anciennes version de jeedom d’ou le faite que je n’ai dit de les enlever

Et comme deja dit ce n’est pas obligatoire si ca vous semble trop compliqué a utiliser ou pas assez documenté (c’est normale ca ne l’est pas encore ca arrivera après quand je trouverais le temps de faire la doc) vous pouvez simplement ignorer cet article.

Bonjour,

Pour les versions c’est la version minimum nous ne gérons pas au numéro de version voulu. De toute façons je recommande d’éviter cela car ça pourrait poser des soucis de conflit entre plugin

Je sais et je suis d’accord mais il y a des cas connus ou faire l’upgrade casse tout à coup sur
Parfois ca depend de la version de l’os aussi.
mais on est d’accord qu’on ne sait pas tout gérer par un système global, en tout cas pas dans sa première version; à voir si ca devra faire l’objet d’une nouvelle feature plus tard ou pas

Oui oui il y a des évolutions prévu mais je préfère y aller petit a petit histoire d’avoir une base solide avant d’aller plus loin

Je sais, mais entre l’annonce l’année dernière en mode « pour info mais pas touche c’est pas sec et ca n’est pas pret » et là pouf communication light à tous alors que c’est pas généralisé …
Mais un jour @Alexandre va reprendre la mailing dev que loic ne connait pas j’espère …

1 « J'aime »

Pas de problèmes de toute façon finalement y’a rien qui change vu que le système actuel continue de fonctionner normalement.

Dès que t’auras le temps de mettre le nez dans le nouveau système tu verras qu’il est assez simple à appréhender et très efficace… c’est que du bonheur !


par contre les logs sont assez moche pour les endusers et dans mes essais, l’install est bloquée en cours à 9%…

Oui, de base je préfère le déclaratif, donc là c’est une bonne avancée réclamée depuis longtemps. Donc même si l’ancien système continue de fonctionner, tout ce qui peut passer sur le nouveau mode simplifie la maintenance (et ca forcera au passage les utilisateurs à upgrader leur core)

1 « J'aime »

Log moche pour les end user => normalement c’est fait pour les dev pas pour les end user
pour le plantage je dirais qu’il manque ton script de post-install.sh d’après la log

ah ok, je l’ai pas encore fait donc c’est probablement ca qui bloque en effet.

oui mais si pas d’erreurs c’est pas nécessaire d’afficher du blabla inutile… je vais rester avec mes jolis logs explicites et qui traitent les retours des fonctions ou cache les retours des fonctions inutiles pour l’instant…

== Jeedom 4.2.7 sur Debian GNU/Linux 10 (buster)/amd64/x86_64/64bits aka 'diy' avec nodeJS v14.18.2 et jsonrpc:enable et homebridge (beta) b0dc4d8e332ebd1f67c9a029c9e20f80a0a40cf2
======================================================================
== 17/01/2022 15:55:15 == Installation des dépendances de homebridge
======================================================================
[  0% ] : Vérification des droits...
[  4% ] : Vérification des droits : [  OK  ]
[  5% ] : Mise à jour APT et installation des packages nécessaires...
[  9% ] : Mise à jour APT et installation des packages nécessaires : [  OK  ]
[ 10% ] : Prérequis...
[ 14% ] : Prérequis : [  OK  ]
[ 15% ] : Installation des packages nécessaires...
[ 19% ] : Installation des packages nécessaires : [  OK  ]
[ 20% ] : Vérification du système...
[ 24% ] : Vérification du système : [  OK  ]
[ 25% ] : Vérification de la version de NodeJS installée...
[Check Version NodeJS actuelle : v14.18.2 : [  OK  ]
[Check Prefix : /usr and sudo prefix : /usr and www-data prefix : /usr : [  OK  ]
[ 49% ] : Vérification de la version de NodeJS installée : [  OK  ]
[ 50% ] : Nettoyage...
[ 59% ] : Nettoyage : [  OK  ]
[ 60% ] : Nettoyage anciens modules...
[ 69% ] : Nettoyage anciens modules : [  OK  ]
[ 70% ] : Installation de Homebridge beta, veuillez patienter svp...
[ 89% ] : Installation de Homebridge beta, veuillez patienter svp : [  OK  ]
[ 90% ] : Configuration Avahi...
[ 99% ] : Configuration Avahi : [  OK  ]
[100% ] : Terminé !
======================================================================
== OK == Installation Réussie
======================================================================

C’est un point de vue, pour moi c’est un log pour les devs il faut un maximum d’information, que ca soit moche c’est pas genant.

oui, mais si le retour d’une commande est 0 a-t-on besoin de ces logs ?

bref, autre sujet qui demanderait une réflexion plus profonde aussi

Moi oui en tout cas meme quand ca se passe bien j’ai besoin de savoir ce qu’il sait passer pour voir après quand ca c’est mal passé ce qu’il y a eu avant.

Information est un incomptable en anglais donc pas de pluriel.

Antoine