La gestion des dépendances est bien plus complexe que ce que tu semble croire. Beaucoup plus complexe.
Il y a généralement beaucoup de conflit entre des besoins différents par des gens différents.
le développeur
Son cheval de bataille c'est les fonctionnalités (c'est ce que les utilisateurs demandent).
C'est celui qui code l'appli. Il a un besoin primordial : gérer les dépendances en dehors du système. Il doit pouvoir avoir différentes versions d'une même bibliothèque sans détruire son système y compris un build de la version pas encore sorti.
Ensuite il a des besoins: comme l'envi de ne pas avoir à supporter des versions de dépendance toujours plus exotiques, ne pas être contraint par les cycles de vie de chaque SE et distributions, ne pas empaqueter des millions de fois son logiciel,...
opérationnel/admin sys
Lui quand on lui parle fonctionnalités, il voit nouveaux bugs.
Son besoin primordial c'est que les logiciels fonctionnent bien sur son système et pour ça il faut que le logiciel se plie totalement à son système. Donc utilise le système de packaging qui va bien, les dépendances du système uniquement, si vraiment une dépendance n'existe pas sur le système (pourquoi diable être allé chercher cette obscure dépendance ?) la packager séparément, etc
(évidemment j'exagère)
Les 2 points de vues ne sont pas réconciliables ils sont opposés. Le seul endroit où ça peut fonctionner c'est dans le cadre du devops où il n'y a qu'une seule cible de déploiement et les ops et les dev discutent. Aucun langage n'a résolu cette problématique, absolument aucun. Ni les vieux comme C ni les plus jeunes comme rust ou julia. Ceux qui te semblent avoir réussi ont juste privilégiés ton point de vue.
[^] # Re: Bazar!
Posté par barmic 🦦 . En réponse à la dépêche Python — partie 3 — Installation de Python et de paquets. Évalué à 2.
Bon je me lance...
La gestion des dépendances est bien plus complexe que ce que tu semble croire. Beaucoup plus complexe.
Il y a généralement beaucoup de conflit entre des besoins différents par des gens différents.
le développeur
Son cheval de bataille c'est les fonctionnalités (c'est ce que les utilisateurs demandent).
C'est celui qui code l'appli. Il a un besoin primordial : gérer les dépendances en dehors du système. Il doit pouvoir avoir différentes versions d'une même bibliothèque sans détruire son système y compris un build de la version pas encore sorti.
Ensuite il a des besoins: comme l'envi de ne pas avoir à supporter des versions de dépendance toujours plus exotiques, ne pas être contraint par les cycles de vie de chaque SE et distributions, ne pas empaqueter des millions de fois son logiciel,...
opérationnel/admin sys
Lui quand on lui parle fonctionnalités, il voit nouveaux bugs.
Son besoin primordial c'est que les logiciels fonctionnent bien sur son système et pour ça il faut que le logiciel se plie totalement à son système. Donc utilise le système de packaging qui va bien, les dépendances du système uniquement, si vraiment une dépendance n'existe pas sur le système (pourquoi diable être allé chercher cette obscure dépendance ?) la packager séparément, etc
(évidemment j'exagère)
Les 2 points de vues ne sont pas réconciliables ils sont opposés. Le seul endroit où ça peut fonctionner c'est dans le cadre du devops où il n'y a qu'une seule cible de déploiement et les ops et les dev discutent. Aucun langage n'a résolu cette problématique, absolument aucun. Ni les vieux comme C ni les plus jeunes comme rust ou julia. Ceux qui te semblent avoir réussi ont juste privilégiés ton point de vue.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll