C'est le truc le plus moche qui existe en gestion de dépendances et de paquets. Je suis pas fan de python, beaucoup de monde le sait ici, et la gestion des dépendances est pour moi le "reflet" de l'état d'esprit du monde python.
Je ne dis pas que je n'ai jamais eu de problèmes avec ruby, mais je trouve que c'est beaucoup plus cohérent. Et même nodejs et npm me posent moins de souci.
Je pense que le meilleur moyen de gérer ce genre de souci avec Python, c'est de tout faire dans un conteneur. Et éviter Python comme langage de script secondaire. C'est certes un investissement en temps, mais une fois que c'est fait, on arrive à s'en sortir. Et l'avantage d'un conteneur, c'est que ton image, une fois en prod, tu la versionnes et la stocke dans un repo d'image. Et elle fonctionnera toujours. Si tu dois générer une image version N+1, et qu'il y a un problème, tu peux toujours revenir à la version N. Et avec un bon système de build (chaine de CI standardisée) tu masques une grande partie de la complexité aux devs.
# Personnellement j'évite Python ...
Posté par totof2000 . En réponse au journal La cochonnerie en boite que sont les systèmes de dépendances. Évalué à 6.
C'est le truc le plus moche qui existe en gestion de dépendances et de paquets. Je suis pas fan de python, beaucoup de monde le sait ici, et la gestion des dépendances est pour moi le "reflet" de l'état d'esprit du monde python.
Je ne dis pas que je n'ai jamais eu de problèmes avec ruby, mais je trouve que c'est beaucoup plus cohérent. Et même nodejs et npm me posent moins de souci.
Je pense que le meilleur moyen de gérer ce genre de souci avec Python, c'est de tout faire dans un conteneur. Et éviter Python comme langage de script secondaire. C'est certes un investissement en temps, mais une fois que c'est fait, on arrive à s'en sortir. Et l'avantage d'un conteneur, c'est que ton image, une fois en prod, tu la versionnes et la stocke dans un repo d'image. Et elle fonctionnera toujours. Si tu dois générer une image version N+1, et qu'il y a un problème, tu peux toujours revenir à la version N. Et avec un bon système de build (chaine de CI standardisée) tu masques une grande partie de la complexité aux devs.