Github : Mise à jour des packages python automatique

Salon des Développeurs Suggestions dev
1

Bonjour,

Ce sujet fait suite à plusieurs cas, où des utilisateurs ont tenté de mettre à jour des packages python avec plus ou moins de bonheur… (dernier topic en date mais c’est pas le seul)

Jeedom Core n’utilise pas python ni ces packages. il revient donc en principe aux plugins concernés à mettre à jour les packages qu’ils utilisent… Et il est possible d’automatiser cela, coté dev / plugin, on en a de la chance :slight_smile:

Il faut pour cela utiliser un bot Github qui se charge de répercuter ce genre de mise à jour sur nos plugins. Pour Python, les dépendances sont en principe listées dans un fichier requirements.txt sous un format précis. Et c’est donc ce que j’ai fait pour mon plugin LGThinq, voici la méthode :

  1. il faut placer ce fichier .github/dependabot.yml pour « appeler » le bot à vérifier notre dépôt
    jeedom-lgthinq-plugin/.github/dependabot.yml at master · pifou25/jeedom-lgthinq-plugin · GitHub
version: 2
updates:
  # Maintain python pip dependencies
  - package-ecosystem: "pip"
    directory: "/resources"
    schedule:
      interval: "daily"

directory désigne le répertoire où j’ai mis le fichier requirements.txt.
2. Quotidiennement, le bot check les mises à jours, et s’il y a lieu, il vient créer une PR sur mon repo pour propager ces mises à jour. ex:

… et c’est là qu’on a un peu de boulot en tant que dev, il faut vérifier le truc d’une manière ou d’une autre. Puis, pousser sur la branche beta, puis stable.

Pour l’utilisateur, au final il n’aura qu’un plugin à mettre à jour. Et relancer l’installation des dépendances pour le plugin, ça pourrait pas être relancé automatiquement après la maj du plugin ?

Pour aller plus loin, la doc pour les options Dependabot sur Github
Et à priori (pas testé c’est pas mon cas) ça marche avec les dépôts privés

Pour ou contre ? si ça vous plaît, la semaine prochaine je vous fais un tuto sur semantic-release pour automatiser la livraison et le versioning :slight_smile:

4 « J'aime »
2

Et ceux que ca intéresse pour même chose pour NodeJS et le package.json, je l’ai fait là : plugin-aTVremote/.github/dependabot.yml at beta · NebzHB/plugin-aTVremote · GitHub

et ici pour un check Erreurs PHP et Syntaxe NodeJS : plugin-aTVremote/.github/workflows/build.yml at beta · NebzHB/plugin-aTVremote · GitHub et là plugin-aTVremote/package.json at beta · NebzHB/plugin-aTVremote · GitHub et là plugin-aTVremote/.eslintrc.js at beta · NebzHB/plugin-aTVremote · GitHub

oui oui je le fais dans tous les miens

3

Salut,

Merci pour les explications, je reconnais que perso sur les plugins jeedom je n’ai pas (encore) pris la peine de le faire (je l’ai fait pour d’autres projets), mais je vais l’appliquer aussi.
Après on est pas toujours obligé d’appliquer tous les PR reçu, on peut le faire seulement si fix sécu par exemple et au moins le dependabot permet d’être averti automatiquement :slight_smile:

Par contre si je peux me permettre une petite proposition d’amélioration: installer les dépendances python dans un Virtual ENVironnement (VENV):

  • il faut définir le dossier cible (moi je met dans /resources/venv mais si quelqu’un pense qu’il y a mieux qu’il le fasse savoir)
  • installer le paquet apt python3-venv
  • créer le venv: python3 -m venv $VENV_DIR (en supposant donc que $VENV_DIR est le path vers le dossier
  • moi je fais un upgrade wheel aussi (utile voir nécessaire pour plusieurs dépendances si on ne veut pas casser l’install vu qu’on est dans un VENV, sinon le venv va utiliser celui du global): $VENV_DIR/bin/python3 -m pip install --upgrade pip wheel
  • et ensuite installer les dépendances: $VENV_DIR/bin/python3 -m pip install -r requirements.txt

la différence consiste donc « juste » à créer le venv et appeler le bin python de notre venv lors de l’install et aussi bien sur lors du lancement du démon (dans la class du plugin)

=> avantage: on n’est plus impacté par les requierements des autres plugins et vice versa

4 « J'aime »
4

Je le fait aussi pour atvremote, je vais ajouter la mise à jour wheel, je l’avais mis de côté car je pensais que ça servait pas/peu au final.

Faudrait pas faire cryptography aussi qui est le problème dans quasi tous les problèmes que je vois en python ?

5

N’ayant pas encore rencontré ce problème personnellement je ne sais pas

1 « J'aime »
6

je crois que c’est la lib qui est un peu de la merde…

elle build pas même chez eux…

image
image1249×707 41.6 KB

1 « J'aime »
7

Le problème avec cryptography c’est si la version du fichier wheel n’existe pas pour l’archi concernée a un instant donné , cela nécessite alors une compilation avec rust. Exemple plugin zigbee.

akenad :slight_smile:

1 « J'aime »
8

Merci pour vos retours :slight_smile:
Je vais essayer de mettre mon demon sous VENV, je n’avais pas réussi quand j’ai fait le plugin, il se lançait juste pas, ou pas avec les paramètres.

Dans l’idéal, maintenant qu’on a un plugin Docker, on devrait juste mettre tous nos démons dans un conteneur distinct, c’est encore mieux isolé qu’un VENV.

Je n’ai pas wheels installé mais j’ai cryptography, je ne sais pas pourquoi ni pour quel plugin il est installé, pas le mien en tout cas. Piwheels semble spécifique aux raspberry pi, est-ce que cette lib n’existe pas pour d’autres systèmes ?

9

Bonjour,

J’ai fait une PR sur le plugin template pour ajouter un exemple de dependabot.yml avec quelques liens

1 « J'aime »