Gestion de packages V4.2

Salon des Développeurs Core V4 (dev)
1

Bonjour,
Pour informations en v4.2 il est possible de confier en partie la gestions des dépendances de vos plugins au core. C’est assez simple il suffit de créer un fichier packages.json dans plugin_info (ca sera bien sur documenté avec la sortie en stable de la 4.2, comme d’habitude pas de date). Voici quelques exemples :

{
  "apt" : {
    "git" : {},
    "python-pip" : {},
    "python-dev" : {},
    "python-pyudev" : {},
    "python-louie" : {},
    "python-setuptools" : {},
    "make" : {},
    "build-essential" : {},
    "libudev-dev" : {},
    "g++" : {},
    "gcc" : {},
    "python-lxml" : {},
    "unzip" : {},
    "libjpeg-dev" : {},
    "python-serial" : {},
    "python-requests" : {}
  },
  "pip2":{
    "wheel" : {},
    "urwid" : {},
    "louie" : {},
    "six" : {},
    "tornado" : {}
  },
  "post-install" : {
    "script" : "plugins/openzwave/resources/post-install.sh"
  }
}

{
  "apt" : {
    "libav-tools" : {"alternative" : ["ffmpeg"]},
    "ffmpeg" : {"alternative" : ["libav-tools"]},
    "python-pil" : {},
    "php-gd" : {}
  },
  "post-install" : {
    "restart_apache" : true
  }
}

{
  "apt" : {
    "python3" : {},
    "python3-pip" : {},
    "python3-pyudev" : {},
    "python3-requests" : {},
    "python3-setuptools" : {},
    "python3-dev" : {}
  },
  "pip3" : {
    "wheel" : {},
    "pyserial" : {},
    "tornado" : {},
    "zigpy" : {"reinstall" : true},
    "zha-quirks" : {"reinstall" : true},
    "zigpy-znp" : {"reinstall" : true},
    "zigpy-xbee" : {"reinstall" : true},
    "zigpy-deconz" : {"reinstall" : true},
    "zigpy-zigate" : {"reinstall" : true},
    "zigpy-cc" : {"reinstall" : true},
    "bellows" : {"reinstall" : true}
  }
}

Actuellement il gère : apt, pip2 et pip3, avec possibilité de lancer des script de pre/post installation et de lui demander un restart d’apache en post.

Si le fichier est présent le core ne se base QUE SUR CELUI-CI, il ignore les fonctions dependancy_info et dependancy_install. Il va donc uniquement calculer si il y a des trucs a installer ou non a partir de ce fichier json.

Ce n’est qu’un premier jet, il y a surement plein de manquement et de bug (on est en alpha). Ce qu’il va y avoir plus tard :

  • gestion de l’installation de nodejs (c’est la misère ce truc en théorie faudrait prendre celui du dépôt mais c’est la v10 je crois c’est trop vieux pour certain plugin). Pouvez me dire la version de nodejs que vous voulez en général ? Si vous avez des idées de comment gerer ca au mieux (nvm peut etre mais je connais pas du tout)
  • il n’y aura pas de gestion de npm ou au mieux juste le repertoire ou se trouve le fichiers des packages que veux npm
  • peut etre un systeme de packges non voulu (a voir c’est costaud car va falloir gerer les conflits)
  • peut etre un champs pour indiquer la version OS min/max supporté par le plugin

Voila pour les idées prévu a l’avenir sur le systeme (nodejs étant la priorité)

2 « J'aime »
2

Hello,

Cela est peux être bête, mais je verrais bien sur le market un endroit ou on peux voir les dépendance ainsi que les system minimum. Sa permettrais au user de simplifié le truc :slight_smile:

Cordialement
Thibaut

3

C’est prévu aussi un jour mais on est loin de ce niveau la pour le moment (mais c’est bien pour ca que c’est un json dans le plugin_info)

1 « J'aime »
4

Bonjour Loic,

pour l’instant nous avions convenus NodeJS 12 entre tous les devs (c’était la LTS jusqu’à il y a peu).

voir cette discussion :

à la fin de celle-ci je lance un appel pour passer à la nouvelle LTS la 14. qui pour moi est la version vers laquelle il faudrait partir.

nvm peut être une solution en effet … mais chaud à mettre en place car à partir du moment ou tu le mets, tout le monde DOIT passer sur ce système en meme temps, sinon risque de problème…

j’avais creusé « n » aussi, dans le même style que nvm mais qui met une version système par défaut (qui me parraissait intéressant ici) mais je t’avoue n’avoir jamais été plus loin que me documenter…

pour l’install de nodejs, j’ai un script assez complet que j’utilise et que je peux te fournir (il bloque l’install sur x86 32 bits, jessie par exemple car nodesource ne founit plus pour ces systèmes) il gère aussi l’install sur armv6 (mini+ par ex) à partir des sources officiellement officieuses (unofficial-builds.nodejs.org) et pas le paquet exotique (node-arm.herokuapp.com dont on est pas certain qu’il va continuer à exister) ainsi que plusieurs correctifs pour corriger des préfix invalides chez certains utilisateurs (du à une modif à la main) etc

à coté de ca, il faut en effet npm… qui s’install avec nodejs mais qu’on peut mettre à jour à la dernière (c’est mieux).

il faudra gérer aussi le fait que un passage de version de nodejs nécessite souvent une recompile sur certains modules (node-gyp… oui je sais c’est chiant)

1 « J'aime »
5

Salut,
Si tu as un script qui gere tout pour nodejs je veux bien (je le mettrais directement dans le core comme ca tout le monde passera dessus). Et oui je suis d’accord pour le passage en v14 quand c’est possible. Sachant que c’est pour le core 4.2 donc forcement c’est du buster (ca doit aider je pense).

Dans l’idée il y aura un truc specifique qui si il voit dans les packages apt du nodejs ou npm il lancement ton script au lieu de passer par le systeme standard.

6

Je confirme le script est plutôt sympa je l’utilise dans plusieurs de mes plugin :slight_smile:

Cdt
Thibaut

1 « J'aime »
7

c’est pas vraiment un script qui fait tout, c’est installation de nodejs :

(je l’ai commenté et simplifié par rapport au mien)

et s’il faut réparer nodejs avant de le lancer je fais :

$cmd = system::getCmdSudo() . 'apt-get -y --purge autoremove npm';
exec($cmd);
$cmd = system::getCmdSudo() . 'apt-get -y --purge autoremove nodejs';
exec($cmd);

@Thibaut_T non j’ai pas mis avec ma lib de dependances pour l’instant :wink:

pour les install npm après il faudra gérer le global et le spécifique à un dossier, donc il faudra à mon avis deux types d’install…

8

Je sait j’ai les 2 :slight_smile:
J’ai recup le code sur alexa API :slight_smile:

Cdt
Thibaut

9

Super merci.

C’est ajouté en alpha, coté plugin dans le packages.json il suffit de mettre :

{
  "apt" : {
    "nodejs" : {}
  },
  "npm" : {
    "plugins/dyson/resources/dysond"  : {}
  }
}

Je sais pas si il est interessant que je gere aussi la commande type npm install -g fs. Vous en pensez quoi ?

2 « J'aime »
10

oui comme je disais moi j’ajouterais dans les options destination : « global » ou destination : « /var/www/html/plugins/monPlugin/resources/ » (et là il faut faire un cd avant d’installer sans -g )

les npm intall moi j’ajoute ces options (pour pas se choper plein d’info inutiles) :

sudo -E -n npm install --no-fund --no-package-lock --no-audit --unsafe-perm -g nomDuPaquet@latest
ou
sudo -E -n npm install --no-fund --no-package-lock --no-audit --unsafe-perm -g nomDuPaquet@1.2.3
ou
sudo -E -n npm install --no-fund --no-package-lock --no-audit --unsafe-perm -g nomDuPaquet@latest
et pour gérer aussi les locaux avec un package.json :
cd /var/...;sudo -E -n npm install --no-fund --no-package-lock --no-audit --unsafe-perm
ou sans :
cd /var/ww...;sudo -E -n npm install --no-fund --no-package-lock --no-audit --unsafe-perm nomDuPaquet@latest

peut-etre aussi gérer les versionning plus précisément avec un version:">=0.1.0 <0.2.0" à mettre là :
cd /var/ww...;sudo -E -n npm install --no-fund --no-package-lock --no-audit --unsafe-perm nomDuPaquet@">=0.1.0 <0.2.0"

11

car la clé c’est le nom du package pas la destination…

"npm" : {
    'nomDuPaquet@">=0.1.0 <0.2.0"'  : {"destination":"global"},
    'nomDuPaquet2@latest'  : {
                   "destination":"/var/www/html/plugins/monPlugin/resources/", 
                   "no-fund":true, 
                   "no-package-lock":true,
                    "unsafe-perm":true,
                    "sudo":true
}
  }

(exemple peut-etre aussi des options no-fund, sudo, force, etc en false par défaut)

(sauf pour du global, faudra peut-etre du sudo : true par défaut…)
(si c’est une destination qui est dans /var/www/html/ il faudrait peut-etre un chown www-data:www-data juste derrière l’install…)

12

ton réinstall true est intéressant aussi…

ceci semble fonctionner :

sudo npm list -g monPackage || sudo npm install -g monPackage

13

petite question, si on a des fichiers à modifier ou des git à cloner ou … on fait comment alors ? un configuration_install() ? ou bien à terme tu vas gérer « git » et « sed » et « awk » etc (ca risque d’être lourd ca non ?)

14

Alors :

  • attention je parle d’installation de npm la avec un fichier package.json pour npm, qui est pour moi la maniere propre de faire. D’ou le faite que c’est juste un path vers le repertoire dans lequel se trouve ce fichier.
15

Je comprends pas la remarque vu que tu peux toujours lancer des scripts pre/post installation perso…

16

Oui c’est la manière propre mais parfois il faut mixer du global et du local

17

De ce que j’ai déjà croisé dans mes script d’install de dep, celles-ci ne s’arrêtent pas à des packages… exemple la compil openzwave ou encore comme je disais un repo à cloner, etc

18

Si tu regardes bien j’ai mis en exemple ce qu’on a fait pour openzwave ou effectivement il y a enormement de chose autre que de la simple installation de packages

19

Pour l’instant on va s’arrêter sur la manière propre a voir si après je rajoute du global (la manière propre faisant deja du local)

20

En effet j’avais pas vu, ça me va comme méthode le post-install

Peut être un pre-install aussi pour tout couvrir ?