Pour avoir eu à migrer une appli toute simple en Python (écrite par quelqu’un d’autre), simplement de RHEL7 vers RHEL8, je vois ce que tu veux dire. Le fait qu’il m’ait fallu, comme l’explique Benoît Sibaud, recourir à pip freeze pour installer très précisément la version X.Y.Z des quatre ou cinq bibliothèques utilisées (de mémoire stomp, request, ... me souviens plus des autres) ça m’a surpris.
Je suis peut-être un vieux con qui n’a rien compris à la vie, ce qui me va parfaitement jusqu’à maintenant, mais lorsqu’il s’agit d’« appli » destinée à répondre à des problématiques de devops, qui ne sont ni énormes ni potentiellement destiné à devoir « passer à l’échelle » comme on dit, je n’ai jamais rien trouvé de plus satisfaisant que Bash. Certes c’est absolument incommode à écrire, bourré de subtiles pièges plus surprenant les uns que les autres, mais une fois que ça fonctionne ça ne va pas casser aussi facilement, simplement parce qu’on passe à une version majeur supérieure du système. La plupart du temps ça fonctionne avec zéro modification. Au pire, il faut voir que Bash 5 (la version actuelle) propose des « mode de compatibilité », pour faire tourner le script écrit il y a 15 (?) ans pour Bash 3.2 et qui tourne depuis, que personne ne veut, ne peut ou n’a les moyens de ré-écrire entièrement, et que les utilisateurs finaux considèrent comme crucial de ne surtout pas perturber.
Ce serait totalement idiot de développer des applications complexes, pour lesquelles le paradigme objet, ainsi que la cohérence et les performances brutes de l’interpréteur sont pratiquement indispensables, en Bash (ou un autre shell), mais ça me semble tout aussi idiot de se priver de l’intégration d’un shell avec le système, qui rend de fait le concept de « déploiement » anecdotique, offert par le shell en la matière.
Attention je n'ai pas dit que l'on ne pouvait pas utiliser pip sous Debian. Juste qu'il faut passer par un environnement virtuel.
OK je vois. Oui le recours à un "Virtual env" pour utiliser Python c’est devenu indispensable. Il faut s’y habituer. C’était une vrai question, je me demandais si tu ne faisais pas référence au fait que pip ne permettait plus l’utilisation de sa fonctionnalité de recherche des dépendances (peut-être est-ce de nouveau possible ? Ça fait un moment que je n’ai pas fait de Python). Pour Bash la recherche, et l’installation, de dépendances ça passe par apt ou dnf, what else !? ^^
Pour résumer le fond de ma pensée : Python est un outil formidable, mais il ne remplace pas le shell, ce sont vraiment deux outils différents, àmha.
Ceci dit pour Python comme pour Bash, le soin à apporter à la sélection des dépendances qu’on va utiliser (leur pérennité, stabilité, notoriété) ne doit pas être négligée.
[^] # Re: Debian ne pip plus ?
Posté par Marotte ⛧ . En réponse au journal La galère de Python en déploiement. Évalué à 6. Dernière modification le 25 décembre 2024 à 05:25.
Pour avoir eu à migrer une appli toute simple en Python (écrite par quelqu’un d’autre), simplement de RHEL7 vers RHEL8, je vois ce que tu veux dire. Le fait qu’il m’ait fallu, comme l’explique Benoît Sibaud, recourir à
pip freezepour installer très précisément la version X.Y.Z des quatre ou cinq bibliothèques utilisées (de mémoire stomp, request, ... me souviens plus des autres) ça m’a surpris.Je suis peut-être un vieux con qui n’a rien compris à la vie, ce qui me va parfaitement jusqu’à maintenant, mais lorsqu’il s’agit d’« appli » destinée à répondre à des problématiques de devops, qui ne sont ni énormes ni potentiellement destiné à devoir « passer à l’échelle » comme on dit, je n’ai jamais rien trouvé de plus satisfaisant que Bash. Certes c’est absolument incommode à écrire, bourré de subtiles pièges plus surprenant les uns que les autres, mais une fois que ça fonctionne ça ne va pas casser aussi facilement, simplement parce qu’on passe à une version majeur supérieure du système. La plupart du temps ça fonctionne avec zéro modification. Au pire, il faut voir que Bash 5 (la version actuelle) propose des « mode de compatibilité », pour faire tourner le script écrit il y a 15 (?) ans pour Bash 3.2 et qui tourne depuis, que personne ne veut, ne peut ou n’a les moyens de ré-écrire entièrement, et que les utilisateurs finaux considèrent comme crucial de ne surtout pas perturber.
Ce serait totalement idiot de développer des applications complexes, pour lesquelles le paradigme objet, ainsi que la cohérence et les performances brutes de l’interpréteur sont pratiquement indispensables, en Bash (ou un autre shell), mais ça me semble tout aussi idiot de se priver de l’intégration d’un shell avec le système, qui rend de fait le concept de « déploiement » anecdotique, offert par le shell en la matière.
OK je vois. Oui le recours à un "Virtual env" pour utiliser Python c’est devenu indispensable. Il faut s’y habituer. C’était une vrai question, je me demandais si tu ne faisais pas référence au fait que pip ne permettait plus l’utilisation de sa fonctionnalité de recherche des dépendances (peut-être est-ce de nouveau possible ? Ça fait un moment que je n’ai pas fait de Python). Pour Bash la recherche, et l’installation, de dépendances ça passe par
aptoudnf, what else !? ^^Pour résumer le fond de ma pensée : Python est un outil formidable, mais il ne remplace pas le shell, ce sont vraiment deux outils différents, àmha.
Ceci dit pour Python comme pour Bash, le soin à apporter à la sélection des dépendances qu’on va utiliser (leur pérennité, stabilité, notoriété) ne doit pas être négligée.