Un des poncifs de la programmation est l'expression "qu'il ne faut pas réinventer la roue" — négligeant que celui qui sait réinventer la roue est au passage tout sauf un potiron. C'est en suivant un peu aveuglément ce poncif mille fois ressassé qu'on se retrouve avec des milliers de dépendances banales et parfois un peu triviales, or comme tu le dis
Il est de bon ton de nos jours pour chaque langage de programmation qui se respecte de débarquer avec un système intégré de dépendances
et c'est justement difficile d'écrire un bon système de dépendances! Or là tout le monde réinvente la roue, encore et encore! Il faut aussi souligner que le problème de la résolution de dépendances des paquets n'est pas facile, c'est même un problème NP-complet et avec un peu de soin on peut montrer que le problème de l'installation est équivalent au problème de la satisfaisabilité d'un polynôme booléen. Autrement dit, c'est exactement le type de problèmes où la réinvention de la roue.
Pour le problème concret qui pousse à cela c'est qu'on voit malheureusement que la distribution de logiciels sous Linux est un cauchemar et qu'il n'y a pas de solution satisfaisante offerte par les gestionnaires de paquets "traditionnels". (Au passage les systèmes de ports à la BSD ou MacPorts eux tirent assez bien leur épingle du jeu pour la distribution de logiciels "maison".)
Une solution pragmatique est celle d'utiliser un environnement de type docker pour distribuer "le python officiel" de l'équipe pour le projet mais cela ajoute un petit peu de complexité dans le cycle de développement.
# Réinventer la roue
Posté par Michaël (site web personnel) . En réponse au journal La cochonnerie en boite que sont les systèmes de dépendances. Évalué à 7.
Un des poncifs de la programmation est l'expression "qu'il ne faut pas réinventer la roue" — négligeant que celui qui sait réinventer la roue est au passage tout sauf un potiron. C'est en suivant un peu aveuglément ce poncif mille fois ressassé qu'on se retrouve avec des milliers de dépendances banales et parfois un peu triviales, or comme tu le dis
et c'est justement difficile d'écrire un bon système de dépendances! Or là tout le monde réinvente la roue, encore et encore! Il faut aussi souligner que le problème de la résolution de dépendances des paquets n'est pas facile, c'est même un problème NP-complet et avec un peu de soin on peut montrer que le problème de l'installation est équivalent au problème de la satisfaisabilité d'un polynôme booléen. Autrement dit, c'est exactement le type de problèmes où la réinvention de la roue.
Pour le problème concret qui pousse à cela c'est qu'on voit malheureusement que la distribution de logiciels sous Linux est un cauchemar et qu'il n'y a pas de solution satisfaisante offerte par les gestionnaires de paquets "traditionnels". (Au passage les systèmes de ports à la BSD ou MacPorts eux tirent assez bien leur épingle du jeu pour la distribution de logiciels "maison".)
Une solution pragmatique est celle d'utiliser un environnement de type docker pour distribuer "le python officiel" de l'équipe pour le projet mais cela ajoute un petit peu de complexité dans le cycle de développement.