Jeedom Versioning et Packages

Jeedom Versioning and Packages !

Voici une étude rapide des versions des composants de Jeedom et leurs dépendances.

Jeedom est basé sur Debian

Il n’y a pas de prérequis clair dans les docs donc j’ai supposé les versions minimales suivantes:

Jeedom v3.x
Debian > (deprecated Jessy 8 / PHP5.6) Stretch 9 / PHP7

Jeedom v4.0
Debian > Stretch 9 / PHP7.0

Jeedom v4.1
Debian > Stretch 9 / PHP7.0

Projection possible pour le futur:

Jeedom v4.2
Debian > Buster 10 ? / PHP7.3

Jeedom v5 … ? PHP8 ? :smiley:

PHP Release

Chaque nouvelle version est maintenue pendant 3 ans. En fait 2 pour les mises à jour,
et 1 année supplémentaire pour les secutiry fix…

PHP 7.2 jusqu’au 30 Novembre 2020
PHP 7.3 jusqu’au 6 Décembre 2021
PHP 7.4 jusqu’au 28 Novembre 2022

Et oui, la version 7.0 de PHP n’est déjà plus maintenue depuis presque 2 ans.
Pour vérifier votre version:
php --version

Python Release

Comme de nombreux plugins Jeedom utilisent Python, il est bien de s’y intéresser également :slight_smile:
Pour quelque obscure raison historique, Debian vient toujours avec 2 Versions de Python:

Debian Jessie contains Python 2.7, 3.4
Debian Stretch contains Python 2.7, 3.5
Debian Buster contains Python 2.7, 3.7

Pour vérifier vos versions:

python --version
python3 --version

sources:

Releases Debian - Releases PHP - Releases Python - Versions PHP dans Debian - Versions Python dans Debian - Compatibilité Jeedom

PHP Library

Les lib PHP sont en principe mises à jour par le gestionnaire de dépendances PHP composer
et donc référencées dans le fichier composer.json .

composer.json sur la branche V4-stable:

« mtdowling/cron-expression »: « ~1.0 »,
« symfony/expression-language »: « ~2.6 »,
« doctrine/cache »: « ^1.6 »,
« monolog/monolog »: « ~1.17 »,
« knplabs/github-api »: « ~1.7 »,
« pragmarx/google2fa »: « ~1.0 »,
« touki/ftp »: « ~1.2 »,
« league/flysystem-webdav »: « ~1.0 »,
« league/oauth2-client »: « ~2.3 »,
« matthiasmullie/minify »: « ~1.3 »

à noter que ce fichier fixe aussi la version de PHP = 7.0 sur la branche v4-stable

A priori ce fichier n’est pas mis à jour, vu que toutes les libs sont versionnées dans le rep /vendor.
D’ailleurs il y a des packages dans /vendor qui ne sont pas référencées dans le fichier composer.json

Par ailleurs il y a des packages qui ne sont plus maintenus, voici le message que j’ai eu en faisant compose update

Package guzzle/guzzle is abandoned, you should avoid using it. Use guzzlehttp/guzzle instead.
Package mtdowling/cron-expression is abandoned, you should avoid using it. Use dragonmantank/cron-expression instead.

Néanmoins il serait bon de tenir à jour la liste des dépendances PHP de Jeedom.
La théorie voudrait qu’on n’ai aucune lib versionnée dans dans Github /vendor, on devrait les installer après l’install du core jeedom, en utilisant l’outil composer.
On peut voir dans /vendor/composer/installed.json le détail des packages installés.

JS Library

Et ce n’est pas tout, car on a maintenant les lib côté client (Javascript Css & co)
Les fameuses 3rdparty : citons JQuery, qui vient lui même avec tout un tas de plugins, Font-Awesome, Bootstrap, Node.js …

Ici aussi c’est la foire, je n’ai pas trouvé d’équivalent au ‹ composer.json › pour lister les packages et les versions…
Les outils de packaging JS / CSS existent (Npm ou Yarn …) je n’en connais aucun donc je ne me prononce pas.
Mais à minima on devrait en choisir un et s’y tenir.

Python

Cet inventaire à la prévert ne serait pas complet sans évoquer également les packages python :smiley: Si Jeedom core est full PHP, certains plugins peuvent utiliser des lib Python, qui s’installent avec un gestionnaire de paquets spécifique « pip » ( via l’installation de dépendances spécifique de chaque plugin ) avec là encore son lot de versions et d’incompatibilités…

Le plugin z-wave utilise la lib OpenZWave (qui est en fait une lib C++ avec un wrapper python)

Core et packages systèmes

Le core gère ses packages système (au travers du gestionnaire de packages Debian, qui est ‹ apt ›) et on peut les vérifier via la page dédiée Jeedom : Configuration > OS/DB > bouton ‹ Gestionnaire de Package ›
Ou sinon on peut voir dans la page ‹ Santé › de Jeedom un résumé succinct: versions du Core Jeedom, version de l’OS Debian, version PHP et Mysql.

Conclusion

Les versions PHP sont maintenues 3 ans. Pour PHP7.0 la version officielle de notre version actuelle de jeedom v4.0… Elle est déjà End of Life, plus de mise à jour même de sécurité.

Pour Debian c’est un peu plus long grâce au support LTS (Long Terms Support) jusqu’à 2022 pour Stretch par exemple

Outre cela, il faut également tenir compte des évolutions des librairies tierces (packages PHP ou Javascript) qui ont leur propre versionning, incompatibilité, etc.

Et chaque plugin Jeedom est susceptible d’en rajouter une couche. Voire d’installer 2 fois le même package sous 2 versions différentes - et là, c’est le drame!

Et vous ? Quelle package PHP / JS utilisez-vous et sous quelle version ? :slight_smile:

(il nous faudrait une page wiki commune pour mettre à jour un tableau des libs / versions / dépendances…)

4 « J'aime »

Salut pifou, bonne idée.

Je te suggère de compléter ton post en fournissant les commandes permettant aux utilisateurs de trouver comment donner réponse à tes questions. php -v etc…

Hello,

Il y a un PR justement autour du loader composer

Hello,

Bonne initiative, il y a aussi nodejs :

https://community.jeedom.com/t/nodejs-12-migration/1939?u=nebz

Oui bonne initiative, je pense qu’il faudra s’y pencher.

Pour info buster est dans les pre requis de la 4.1 donc php 7.3 :hugs:

Buster, plutot php7.3 non ?
Voir le tableau ici : [Présentation] akenad - #10 par akenad

akenad :slight_smile:

Ah oui, encore mieux !

Librairies PHP référencées dans Composer

A titre de test, j’ai supprimé le répertoire /vendor puis recréé avec la commande composer qui installe juste les dépendances du fichier composer.lock, puis comparé les résultats:
composer install

présent dans /vendor (v4.2) mais pas dans le fichier composer.lock

bacon/bacon-qr-code
dragonmantank/cron-expression
influxdb/influxdb-php
matthiasmullie/minify
ralouphie/getallheaders
sabre/* (6 libs: dav event http uri vobject xml)

présent dans le fichier composer.lock mais pas dans /vendor (v4.2):

(mais pourquoi?)

ircmaxell/random-lib

liste des dépendances dans composer.json:

dragonmantank/cron-expression: *,
symfony/expression-language: *,
doctrine/cache: *,
monolog/monolog: *,
knplabs/github-api: *,
touki/ftp: *,
league/flysystem-webdav: *,
league/oauth2-client: *,
matthiasmullie/minify: *,
pragmarx/google2fa-qrcode: ^1.0

On peut voir par exemple que le package dragonmantank/cron-expression est référencé mais n’a pas été installé, je tente donc une mise à jour avec cette commande:

composer update dragonmantank/cron-expression
Problem 1
- pragmarx/google2fa-qrcode[v1.0.0, …, v1.0.2] require pragmarx/google2fa ~4.0 → found pragmarx/google2fa[v4.0.0, v4.0.1, v4.0.2] but the package is fixed to v1.0.1 (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command.
- pragmarx/google2fa-qrcode v1.0.3 requires pragmarx/google2fa >=4.0 → found pragmarx/google2fa[v4.0.0, v4.0.1, v4.0.2, v5.0.0, v6.0.0, v6.0.1, v6.1.0, v6.1.3, v7.0.0, 8.0.0] but the package is fixed to v1.0.1 (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command.
- Root composer.json requires pragmarx/google2fa-qrcode ^1.0 → satisfiable by pragmarx/google2fa-qrcode[v1.0.0, v1.0.1, v1.0.2, v1.0.3].

Je n’insiste pas :slight_smile: je ne sais pas du reste si les lib manquantes sont vraiment encore utilisées dans jeedom-core (et je ne les connais pas…) Si oui, au pire on doit faire un composer update pour faire une mise à jour globale des libs avec leur dépendances et du fichier composer.lock

La semaine prochaine je fais le même exercice avec les 3rdparty (packages JS installés je suppose par… npm ?)