• [^] # Re: Composer, pip, npm, gem, go-get et cargo, ces nouveaux SPOF des temps modernes...

    Posté par . En réponse à la dépêche Moi, expert C++, j’abandonne le C++. Évalué à 9. Dernière modification le 08 juin 2019 à 17:25.

    Sauf que créer un paquet npm (ou pip, gem, etc.) me permet de déployer mon code chez des gens qui utilisent n'importe quelle distribution, pas seulement la mienne. C'est autrement plus facile que d'écrire un paquet pour chaque empaqueteur Linux, OSX et BSD.

    Les gestionnaires de paquets spécifiques à une communauté ont des défauts et aussi des avantages. Pour les gens qui attachent plus d'importance à l'appartenance à cette communauté qu'à leur utilisation d'une distribution spécifique, ils sont clairement avantageux. Pour des gens qui utilisent ces travaux communautaires comme un paquet parmi d'autre au sein d'un système donné, ils sont clairement moins commodes qu'un empaquetage de distribution.
    Je trouve un peu triste qu'on répète ce débat à chaque fois, chaque personne donnant seulement un des points de vue ("développeur Javascript", "admin Debian", etc.), ce qui ne permet pas de comprendre la situation.

    Par ailleurs je remarques que les empaqueteurs des distributions sont très lents à réagir à de nouveaux besoins. Les développeurs sont très clairs sur le fait qu'ils ont besoin de travailler sur plusieurs projets qui vont utiliser chacun une version différente d'un paquet donné. Quels sont les gestionnaires de distributions qui permettent ça facilement ? À ma connaissance il n'y a que Nix et Guix qui font un bon boulot là-dessus, alors que pourtant c'est un besoin qui est apparu il y a des années. C'est bien beau de venir ensuite faire la morale "non mais les gestionnaires paquage-spécifique c'est puéril, il suffit d'utiliser Rpm/Deb/whatever".