Option "reinstall" des dependances: best practise?

Salon des Développeurs Suggestions dev
1

salut

Je me pose des questions existentielles sur les effets de bord de l’install de mon plugin:
est-il conseillé de forcer la réinstall (et donc la maj) des packages ou pas?
Quid des effets de bord sur les autres plugins?

  "pip3": {
    "wheel" : {"reinstall" : true},
    "requests" : {"reinstall" : true},
    "pyudev" : {"reinstall" : true},
    "six" : {"reinstall" : true},
    "pyserial" : {"reinstall" : true},
    "websocket-client" : {"reinstall" : true}
  },

La doc et ce thread ne donnent pas de consignes claires sur le sujet
Merci pour vos recos

2

Bonjour,

vous avez aussi la possibilité d’utiliser pyenv pour isoler une installation de python avec ses propres modules. J’ai écrit un post la-dessus il y a quelques temps. Le plugin MyModbus en bêta fonctionne avec pyenv et un autre plugin aussi depuis, mais je ne sais plus lequel.

A+
Michel

3

si c’est pour isoler ses packages du système dans un environnement virtuel, c’est peut-être préférable d’utiliser la méthode documentée par python directement: venv — Creation of virtual environments — Python 3.11.6 documentation (btw il y a du changement à prévoir sur debian12 à ce niveau, pour le core aussi du coup)

mais ici la question concerne l’utilisation de {"reinstall" : true} via l’installation gérée par le core

4

Merci @Michel_F @Mips mais ca ne repond pas a ma question initiale: quelle est la reco pour l’install via le core? Reinstall systématique ou pas?

5

je ne sais pas
je ne pense pas qu’il soit possible de donner une réponse toujours valable, ca va dépendre de la lib

pareil (surtout l’inverse en fait: l’effet de bord de l’install des autres plugins) c’est bien pour ca que la plupart du temps j’utilise en venv… mais ca ne répond pas à ta question :wink:

6

en effet un venv permet d’isoler l’environnement et est moins gourmand en place.
un pyenv permet d’utiliser une autre version de python et d’isoler cette installation. btw, il est possible d’utiliser des venv dans un pyenv.

7

Merci pour vos retours
Si je comprends bien ca va changer bientôt donc il est urgent d’attendre…

8

Hello,

… une autre version de python !? il y a des cas d’usage de ce besoin ? Aujourd’hui python2 n’est plus, depuis debian 11, donc on devrait tous n’utiliser que python 3, et dans ce cas pourquoi se restreindre à une version spécifique ?

Pour cette fameuse option « reinstall » l’effet de bord que j’imagine, et pas des moindres, c’est que ça risque juste d’installer une nouvelle version, par rapport à une version existante utilisée par un autre plugin. D’un autre côté, si tu ne force pas la reinstall, tu risque de te retrouver avec une ancienne version du package, pas forcément compatible avec ton nouveau plugin…

Une bonne pratique serait de fixer à minima la version majeure du package pour s’assurer de ne pas avoir de saut de version, et pas de régression. Est-ce possible sur ce fichier ? Mais, en faisant cela, on va au devant de conflits, entre 2 plugins qui vont demander des versions différentes d’un même package…

chaque langage a son propre gestionnaire de package, qui lui-même a son propre fichier pour configurer / fixer les packages et leur version !

  • php => composer => composer.json & composer.lock => répertoire /vendor
  • nodeJS => npm => packages.json & packages.lock => rep /node_modules
  • python => pip => requierment.txt mais pas de lock (sais pas pourquoi) => /venv

Le fichier lock est utile pour résoudre les conflits. Il fixe les versions et on ne peut pas le générer tant qu’il y a des conflits dans la coniguration du json.

Une bonne pratique, c’est de versionner dans git le fichier des packages (le json et le lock) mais pas le répertoire des lib installées. Le développeur met à jour ces fichiers lorsqu’il y a des updates des librairies. L’utilisateur met à jour les plugins et l’installation des dépendances met à jour les dernières versions des lib.

Sur nos plugins on devrait appliquer ces consignes mais on risque les conflits de version: un ancien plugin demande la v1 d’une lib quand un autre plus récent veut la v2, forcément pas compatible… Comment corriger ce conflit ?

les venv pour python sont une solution à ce problème - 1 package par plugin isolé dans son propre venv - mais l’installatiotn globale proposée par le core n’utilise pas les venv il me semble. C’est donc une question ouverte, et elle concerne aussi plus largement les packages composer & npm.

9

En effet, python 3.7 est installé avec debian 11. Il existe des modules, notamment pymodbus, qui demandent une version supérieure. Pour pymodbus, par exemple, c’est la version 3.8. Pas de bol… Et tout le monde ne tourne pas avec debian 11, certains sont en debian 10 et même raspbian 10 en fait. Et pour ces utilisateurs-là, que je n’ai pas oubliés (mais à qui j’en veux un peu quand même à cause des heures passées), pyenv est franchement bienvenu.

Le reste c’est de la théorie.

10

non il y a mélange

  • debian 10 => python 3.7
  • debian 11 => python 3.9
  • debian 12 => python 3.11
11

ok en effet ça justifie l’utilisation de pyenv, ne serait-ce que pour la compatibilité avec Debian 10 qu’on supporte encore :slight_smile:

12

Oui, je me suis emmêlé les pinceaux. Désolé pour l’erreur.