En Python, Node.js, Ruby, Go, Rust on a pip, npm, gem, go-get, cargo qui simplifie le téléchargement des dépendances, et l’intégration au projet avec un import xxxx. De plus, certains IDE prennent en charge cette gestion des dépendances.
Tu nous cites ça comme de super outil, j'ai une autre vision de la chose.
Ces outils dépendent d'un site internet (piratable), qui va tirer tout un tas de dépendances sans aucun contrôle de ta part.
Il y a déjà eu des exemples où un type t'explique qu'il a ajouté une porte dérobée dans une super librairie de coloration utilisée par plein de monde.
Un système de packaging qui marche, c'est celui de ta distribution ou faut pas hésiter à remonter un patch.
urpmi lib(64)machin(_version)-devel ou yum install lib(64)machin-dev(el?) ou apt-get install lib(64)machin-dev
Comme ça, tu as un suivi de dépendance, la livraison de correctifs de sécurité si le contributeur fait sa veille correctement et le reste. Modulo une compatibilité d'abi de mémoire, tout ça...
Tout ça c'est sans compter sur les temps de déploiement.
Si on prends un exemple PHP, comme cette bouse de composer.
Quand tu veux déployer ton projet, il faut que le site liant projet et adresse de dépôt fonctionne, que TOUS les dépôts git répondent et seulement à la fin ton projet sera prêt à être déployé.
Pour avoir codé une version Perl pour déployer du symfony en prod sans passé par composer, mon code faisait le déploiement en une trentaine de secondes modulo les temps de réponse des dépôts, composer de son côté c'était minimum 5 minutes...
Pour résumer, ces nouveaux outils de gestion de dépendance de nouveaux langages, c'est des catastrophes, codées par des développeurs qui n'ont pas trempé dans la gestion de dépendance des distribution linux. Ils ré-inventent très souvent la roue en codant avec les pieds (et/ou en dépit du bon sens), ajoute une passoire niveau sécurité et des gros SPOF (single point of failure ou point unique de défaillance).
Donc se mettre une dépendance sur ces bouses quand c'est pour un projet perso, pourquoi pas.
Dépendre d'un truc pas fiable quand on a un client à livrer en temps contraint c'est une connerie.
Packager la librairie dans ta distribution t'aurait pris beaucoup moins de temps que ça au final et ça ne t'exploses pas à la figure au moment où tu dois livrer un correctif en urgence ou de sécurité.
# Composer, pip, npm, gem, go-get et cargo, ces nouveaux SPOF des temps modernes...
Posté par Raphaël G. (site web personnel) . En réponse à la dépêche Moi, expert C++, j’abandonne le C++. Évalué à 10.
Tu nous cites ça comme de super outil, j'ai une autre vision de la chose.
Ces outils dépendent d'un site internet (piratable), qui va tirer tout un tas de dépendances sans aucun contrôle de ta part.
Il y a déjà eu des exemples où un type t'explique qu'il a ajouté une porte dérobée dans une super librairie de coloration utilisée par plein de monde.
Un système de packaging qui marche, c'est celui de ta distribution ou faut pas hésiter à remonter un patch.
urpmi lib(64)machin(_version)-devel ou yum install lib(64)machin-dev(el?) ou apt-get install lib(64)machin-dev
Comme ça, tu as un suivi de dépendance, la livraison de correctifs de sécurité si le contributeur fait sa veille correctement et le reste. Modulo une compatibilité d'abi de mémoire, tout ça...
Tout ça c'est sans compter sur les temps de déploiement.
Si on prends un exemple PHP, comme cette bouse de composer.
Quand tu veux déployer ton projet, il faut que le site liant projet et adresse de dépôt fonctionne, que TOUS les dépôts git répondent et seulement à la fin ton projet sera prêt à être déployé.
Pour avoir codé une version Perl pour déployer du symfony en prod sans passé par composer, mon code faisait le déploiement en une trentaine de secondes modulo les temps de réponse des dépôts, composer de son côté c'était minimum 5 minutes...
Pour résumer, ces nouveaux outils de gestion de dépendance de nouveaux langages, c'est des catastrophes, codées par des développeurs qui n'ont pas trempé dans la gestion de dépendance des distribution linux. Ils ré-inventent très souvent la roue en codant avec les pieds (et/ou en dépit du bon sens), ajoute une passoire niveau sécurité et des gros SPOF (single point of failure ou point unique de défaillance).
Donc se mettre une dépendance sur ces bouses quand c'est pour un projet perso, pourquoi pas.
Dépendre d'un truc pas fiable quand on a un client à livrer en temps contraint c'est une connerie.
Packager la librairie dans ta distribution t'aurait pris beaucoup moins de temps que ça au final et ça ne t'exploses pas à la figure au moment où tu dois livrer un correctif en urgence ou de sécurité.