Introduction Jeedom 4.2 : installation de dépendance

Publié sur: Introduction Jeedom 4.2 : installation de dépendance – Jeedom – Le Blog

Un petit article aujourd’hui pour mettre en avant le nouveau système d’installation des dépendances qui arrivera avec Jeedom 4.2 (en beta au moment où j’écris ces lignes). Comment ca marchait avant ? Avant Jeedom 4.2, chaque plugin avait une fonction qui disait si oui ou non il avait tout ce qu’il faut pour fonctionner. Si…

26 « J'aime »

Joli travail, félicitations

Bravo :pray: et merci :wink:

" Comment ca va marcher maintenant ?

Maintenant dans chaque plugin, il pourra y avoir un fichier package.json qui indiquera ce dont le plugin a besoin."

@Loic ca serait pas packageS.json le nom du fichier ?

1 « J'aime »

A si possible petite erreur de frappe je vais regarder pour corriger

1 « J'aime »

Bravo, belle fonctionnalité !

Génial ça ! Ca progresse encore sous le capot et sur l’écran, parfait :grin:

1 « J'aime »

C’est cool d’apprendre en tant que dev que c’est prêt … via le blog.
Sinon, un exemple de fichier accessible publiquement pour que les devs prennent exemple ? Là tous les plugins du screen sont payants et donc non accessible sur github, c’est un peu les boules quand même.

1 « J'aime »

ce n’est pas obligatoire, tu peux toujours utiliser l’ancien système (chose que je ferai car il manque quelques fonctionnalités encore (–unsafe-perm pour npm) et que niveau log, ca va être difficile d’aider les utilisateurs car ils seront un peu partout de ce que j’ai pu comprendre (dans notre pre-script, pos-script, dans jeedom…) mais de ce que j’ai compris comme c’est dans le core, jeedom en ferait le support ?)

j’ai au moins 2 voir 3 ou 4 plugins qui ont juste un paquet en apt en dep, ca sera une facon de commencer

C’est justement le but de l’article du blog de prevenir les utilisateurs ET LES DEV comment aurais tu aimer le savoir ? Le community ca va pas, le blog ca va pas, un telegram ?

Pour l’exemple tu peux prendre ca https://github.com/jeedom/plugin-sonos/blob/beta/plugin_info/packages.json, mais comme dit ce n’est pas obligatoire et l’ancien systeme est toujours la bien sur, c’est juste une aide, mais comme toujours même quand on veut aider ca va pas…

Bonjour,
Pour le unsafe je peux voir pour le gérer en 4.3 (une option peut être a préciser). Pour la log ça dépend comment c’est lancé, si c’est depuis la page de configuration du plugin tu as un log qui contient le nom du plugin avec tout de renvoyé dedans (pre-script, post-script, packages…)

Niveau support ça ne change rien, le systeme essaye de faire au mieux mais si ya des soucis nous n’avons pas forcement les compétences pour comprendre votre plugin, ce dont il a besoin et comment corriger.

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.