Journal Comment 11 lignes de code ont provoqué un #npmgate

Posté par (page perso) . Licence CC by-sa
48
23
mar.
2016

Il était une fois 11 lignes de code qui vivait dans un module npm appelé left-pad :

module.exports = leftpad;
function leftpad (str, len, ch) {
  str = String(str);
  var i = -1;
  if (!ch && ch !== 0) ch = ' ';
  len = len - str.length;
  while (++i < len) {
    str = ch + str;
  }
  return str;
}

Ce module a été écrit par Azer Koçulu et est utilisé indirectement par des projets connus comme ember, babel et react-native. Il se trouve que l'auteur a également écrit d'autres modules pour npm dont l'un, kik, lui a valu des ennuis avec une société du même nom. Kik.com a d'abord demandé à ce que le module soit renommé et, suite au refus de l'auteur, s'est tourné vers npm.com pour faire retirer le module de npm (violation de copyright).

Npm a donné raison à kik.com et Azer Koçulu s'est fâché tout rouge. Pour lui, npm est un terrain privé sur lequel les entreprises ont plus de pouvoir que les humains et ça va à l'encontre de sa vision de l'open-source (Power To The People). Du coup, il a décidé de dépublier tous les paquets npm à son nom. Et ce fût le drame.

La dépublication du module left-pad a entraîné l'échec du build de nombreux projets open-source. Un mainteneur a repris le module et a publié une nouvelle version sur npm. Mais cela n'a pas suffit à corriger le build de beaucoup de projets qui dépendaient d'une version spécifique de left-pad. Du coup, le nouveau mainteneur a demandé à npm de republié la version dépublié, ce qui a été fait même si les avis au sein de l'organisation npm sont partagés. Le CTO de npm le dit lui-même : cette action est dans une zone grise d'un point de vue légal. Rien dans les TOS de npm ne parlent de ce cas de figure (la republication d'un module npm).

On peut lire ici les explications d'Azer Koçulu : I’ve Just Liberated My Modules, et là les tweets du CTO de npm : https://twitter.com/seldo/status/712414400808755200.

Plus largement, on peut se poser la question de la fiabilité des projets JavaScript qui dépendent de centaines de modules npm. Vu le nombre de modules, il faut s'attendre à des problèmes et donc prévoir des solutions. Comment gérer un module dépublié ? Et si un module venait à avoir une faille de sécurité ?

Certains proposent de redécouvrir le linkage statique, d'autres mettent en avant leur outil de packaging, pourtant beaucoup plus jeune mais déjà mieux pensé.

Et pour conclure, voici le tweet de Brad Fitzpatrick :

lol npm

  • # ça se serait passer comment avec une distribution linux style debian ?

    Posté par . Évalué à 4.

    Tout est dans le titre, je sais qu'il y a plus d'un mainteneur debian qui moule sur linuxfr, ça serait intéressant de savoir comment debian gère ce cas de figure.

    • [^] # Re: ça se serait passer comment avec une distribution linux style debian ?

      Posté par (page perso) . Évalué à 10.

      Je pense que le problème vient plus de npm : c'est une entreprise. Je pense qu'une structure comme l'asso Debian ou le Perl NOC pour le CPAN (je ne connais pas le statut de ceux qui gère pypi ou les dépôts des gems Ruby) n'aurait pas supprimé le module suite à une simple menace, ils auraient creusé, contacté le développeur, etc.

      Enfin, c'est mon ressenti, je me trompe peut-être.

      It's a fez. I wear a fez now. Fezes are cool !

    • [^] # Re: ça se serait passer comment avec une distribution linux style debian ?

      Posté par . Évalué à 10.

      Ben justement Debian a des mainteneurs et ne publie que des logiciels libres, la licence permet de continuer à distribuer le logiciel même si l'auteur fait un caca nerveux.

      Là si on voulait faire un parallèle c'est plutôt comme un systeme de build qui récupère directement ses dépendances sur github, il suffit qu'un dépôt forme ou change de nom pour que ça ne marche plus.

    • [^] # Re: ça se serait passer comment avec une distribution linux style debian ?

      Posté par (page perso) . Évalué à 6.

      Avec Debian, tu peux fournir un paquet différent mais qui remplit exactement le même rôle.

      Par exemple, tu peux avoir "JVM" en dépendance, et cette dépendance peut aussi bien être fournie par la JVM d'Oracle qu'OpenJDK (oui, je sais, c'est plus ou moins la même chose maintenant) ou toute autre JVM.

    • [^] # Re: ça se serait passer comment avec une distribution linux style debian ?

      Posté par . Évalué à 8. Dernière modification le 25/03/16 à 11:30.

      Les distributions linux n'arrivent pas à suivre le dependency hell de beaucoup de projets qui utilisent extensivement rubygems, PyPI, npm, etc.

      Par exemple, sous archlinux, on ne peut pas installer plusieurs versions d'un même paquet.
      Donc on doit créer un paquet différent par version pour le même module.
      Comme beaucoup de modules ont des cycles de développement pas très carrés et ultra rapides et cassent régulièrement leur rétro-compatibilité, ça devient vite compliqué et contre productif de repackager 10 versions différentes de chaque gems de rubygems… A mon avis, ça demande énormément de travail de packaging pour des avantages relativement faibles…

      Au final, tout le monde utilise des hacks comme rvm et installent tout dans leur homedir car c'est impossible d'utiliser ruby sans cloisoner chaque projet ruby dans un gemset indépendant…

      Après si on ne se pose plus la question de la pérénité des dépendances, j'ai envie de dire qu'on l'a bien cherché… Peut-être qu'on ne devrait pas dépendre sur des dizaines de modules aléatoires publiés par des inconnus qui n'ont aucune intention de les maintenir à long terme…

      edit: en fait, j'ai mal compris la question et je n'y réponds pas exactement…

  • # Trollons

    Posté par . Évalué à 10.

    lus largement, on peut se poser la question de la fiabilité des projets JavaScript qui dépendent de centaines de modules npm. Vu le nombre de modules, il faut s'attendre à des problèmes et donc prévoir des solutions. Comment gérer un module dépublié ? Et si un module venait à avoir une faille de sécurité ?

    C'est justement ça qui me fait détester npm et node en général.

    Rien n'est jamais packagé (par la distribution) dans la bonne version, il faut donc compiler et installer des milliards de dépendances et ce système est bancal. Tellement bancal qu'on en vient à utiliser Docker comme cache-misère.

    En tant que sysadmin je ne veux pas de node chez moi.

    • [^] # Re: Trollons

      Posté par . Évalué à 7.

      Quelle est la différence avec cpan par exemple ?

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Trollons

        Posté par . Évalué à 8.

        Je n'en veux pas non plus.
        Pareil pour pecl.
        Si la dépendance n'est pas packagée dans la distribution, l'appli va à la poubelle.

        • [^] # Re: Trollons

          Posté par . Évalué à 4.

          Si la dépendance n'est pas packagée dans la distribution, l'appli va à la poubelle.

          Jusqu'à ce que le paquet devienne obsolète / non maintenu …
          En ces temps hystériques, c'est dur de trouver du code stable mon bon monsieur !

          • [^] # Re: Trollons

            Posté par . Évalué à 4.

            Sur Debian les paquets sont maintenus très longtemps.
            Alternativement il y a FreeBSD et ses ports (à compiler ou à récupérer directement sous forme binaire) qui propose différentes versions d'un même logiciel (par exemple il y a php5.5, php5.6 et php7, avec les dépendances en option).

            • [^] # Re: Trollons

              Posté par . Évalué à 10.

              Sur Debian les paquets sont maintenus très longtemps.

              Non, 5 ans c'est bien, mais ce n'est pas « très longtemps ».

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: Trollons

            Posté par . Évalué à 2.

            C'est comme tout, à un moment il faut bien mettre des moyens. En l'occurence il existe des sociétés qui proposent des prestations pour faire du packaging Debian.

      • [^] # Re: Trollons

        Posté par (page perso) . Évalué à 5.

        D'abord, sur le CPAN, il y a une hiérarchie de nom et donc se construit un système de nom de manière collaborative. Il n'y a pas 15000 modules à plat. Ensuite, sur le CPAN, il y a tous les sources avec toutes les versions. On ne va pas chercher à droite et à gauche. La licence est toujours une licence libre. La règle est que le premier qui se sers du nom a le nom, mais tout le monde peut proposer un module dans cet espace de nom.

        Bref, CPAN n'est pas qu'un annuaire…

        • [^] # Re: Trollons

          Posté par . Évalué à 3.

          Je répondais à ça :

          Rien n'est jamais packagé (par la distribution) dans la bonne version, il faut donc compiler et installer des milliards de dépendances et ce système est bancal.

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Trollons

        Posté par (page perso) . Évalué à 8.

        C'est pourtant évident: JavaScript est une technologie maudite par des années d'utilisation par des web-developpers pour faire du front-end et qui n'a rien à faire dans l'horizon d'un sysadmin digne de ce nom, tandis que Perl, c'est le bien, la lumière, et la vraie philosophie Unix. Une bonne vieille querelle de clocher, en somme. – Je sais que tout le monde sait, mais le titre du fil est “trollons” ;)

    • [^] # Re: Trollons

      Posté par . Évalué à 10.

      En tant que sysadmin je ne veux pas de node chez moi.

      Ce que je trouve marrant avec certains sysadmin, c'est comment ils priorisent l'esthétisme de leur système au fait qu'elle servent à quelque chose :)

      Si ce n'est pas packagé (et que tu veux à tout prix passer par là) tu peux packager toi-même (ça ne doit pas être si dur si tu le demande à tout le monde) soit demander à packager.

      Le boulot du sysadmin c'est d'avoir un système propre ou de fournir des services aux utilisateurs ?


      Moi en tant que dev, je suis pas fan de js, mais comme je veux avoir une IHM web qui soit un peu réactive (pas de rechargement complet à tous les cliques), j'utilise js. Je vois pas à quoi ça sert de rester camper sur des paradigmes « j'aime pas donc je boude ».

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Trollons

        Posté par . Évalué à 10. Dernière modification le 23/03/16 à 15:00.

        Simplement parce que le sysadmin c'est lui qui se tape les install, les upgrades, les migration et pas le développeur. Si tout est packagé proprement un dpkg -l suffit à voir ce qui est installé sur ta bécane. Si en revanche s'il faut inspecter dpkg, cpan, pecl, npm, en notant les versions particulières ça devient l'enfer. Avoir un serveur propre c'est le boulot du sysadmin.

        Autre exemple : en cas de maj du kernel ou de libc6, si cela impacte des paquets ils seront mis à jour eux aussi. Par contre tes bidules npm non, c'est à toi de savoir que ça va merder et qu'il faut recompiler.

        • [^] # Re: Trollons

          Posté par . Évalué à -7.

          Si tout est packagé proprement un dpkg -l suffit à voir ce qui est installé sur ta bécane.

          Et pourquoi dpkg est plus "propre" que les autres ?

          Si en revanche s'il faut inspecter dpkg, cpan, pecl, npm, en notant les versions particulières ça devient l'enfer.

          Tu fais quand même pas ça a la main ? T'as pas un stagiaire pour te scripter ça ?

          • [^] # Re: Trollons

            Posté par . Évalué à 8.

            Tu fais quand même pas ça a la main ? T'as pas un stagiaire pour te scripter ça ?

            D'autant que ce n'est pas très compliqué.

            xkcd-1654

        • [^] # Re: Trollons

          Posté par (page perso) . Évalué à 2.

          Par contre tes bidules npm non, c'est à toi de savoir que ça va merder et qu'il faut recompiler.

          Il y a des paquets npm qui nécessitent une compilation ?

        • [^] # Re: Trollons

          Posté par . Évalué à 10.

          Si tout est packagé proprement[…]

          Quelque soit le système de packaging, « si tout est packagé proprement », généralement ça reste propre ;-)

          Simplement parce que le sysadmin c'est lui qui se tape les install, les upgrades, les migration et pas le développeur.

          Les développeurs ne testent pas ça ? Genre ils codent et commit sans jamais rien exécuté et toi tu dois inventer les procédures d'install/update/migration ? :)

          Si en revanche s'il faut inspecter dpkg, cpan, pecl, npm, en notant les versions particulières ça devient l'enfer.

          C'est le développeur qui indique les versions de ce qu'il utilise.

          Avoir un serveur propre c'est le boulot du sysadmin.

          Non, avoir un serveur propre c'est trivial et à la porté du premier venu. Tu télécharge l'iso de l'OS que tu veux, tu l'installe, tu débranche le câble réseau : t'as un serveur propre.

          Le boulot d'un sysadmin (ou d'un devops) c'est de maintenir un serveur qui fournis les services qu'on lui demande et oui ça demande de faire avec les services qu'on lui demande et oui il y a des fois où tu ne va pas pouvoir t'appuyer sur le travail de ta distrib (parce qu'il existe autre chose que SSH/(S)FTP/SMTP). Et oui ça demande de faire autre chose que juste la commande sortie de la doc de ta distrib'

          Par contre t'es ultra outillé pour le faire quand même entre chef, puppet, ansible, salt, fabric et tout ce qui vient avec la mouvance des plateformes immutables (docker entre autre).

          Donc oui c'est du travail, sinon ce ne serait pas payé ;)

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: Trollons

            Posté par . Évalué à -2.

            Toi, tu es soit un développeur pensant connaître le métier de sysadmin/devops, soit ça ne bouge pas beaucoup chez toi.

            • [^] # Re: Trollons

              Posté par . Évalué à 9.

              Tu n'avais rien de plus méchant en stock ? ^_^
              Ou alors fouiller un peu le web pour chercher des casseroles.

              Toi, tu es soit un membre pensant être un troll, soit ça ne bouge pas beaucoup chez toi.


              J'ai pas compris, le « ça ne bouge pas beaucoup chez toi », mais maintenir une intégration continue avec installation de la version N, mise à jour vers la version de dev, passage des tests, puis passages des tests de charge (tout en sachant que ce n'est pas ton boulot, c'est rarement chiffré, c'est sensé être lissé dans ton travail quotidien). Ce n'est clairement pas identique au boulot du sysadmin (et ça ne prévient pas forcément des problèmes que peux rencontrer le sysadmin), mais affirmer que les dev n'ont aucune conscience des problématiques d'admin, c'est juste drôle.

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

              • [^] # Re: Trollons

                Posté par . Évalué à 4.

                affirmer que les dev n'ont aucune conscience des problématiques d'admin, c'est juste drôle.

                donc c'est plus grave alors : ils en ont conscience mais ils s'en fichent royalement !!! Merci pour m'avoir donné un prétexte pour leur taper dessus.

              • [^] # Re: Trollons

                Posté par . Évalué à 3.

                mais affirmer que les dev n'ont aucune conscience des problématiques d'admin, c'est juste drôle.

                Il te visait personnellement, enfin bon libre à toi de généraliser.

                Ceci dit, pour en revenir à nos moutons, j'ai l'impression que tu n'as pas compris la différence entre "version X fonctionne avec mon code" et "la version X est maintenue et fonctionne sur mon système". Par exemple dans le cas de debian, tu as de nombreux logiciels en version X qui ne correspondent pas à la version X de upstream car ils contiennent des corrections supplémentaires. C'est à dire que le sysadmin doit s'assurer non seulement que le logiciel fonctionne en tant que tel, mais aussi en temps que composant d'un système. Alors, à moins de nous avouer que tu développes directement sur la prod en tout bon rambo qui se respecte, j'estime que tu n'a pas prouvé ta légitimité pour pouvoir discréditer les sysadmins… ;-)

                • [^] # Re: Trollons

                  Posté par . Évalué à 1.

                  s/temps/tant;s/ à d/­-à-d/

          • [^] # Re: Trollons

            Posté par . Évalué à 3.

            Le boulot d'un sysadmin (ou d'un devops) c'est de maintenir un serveur qui fournis les services qu'on lui demande

            Fournir le service (au client donc) est indépendant de la «tambouille» interne dev/admin pour savoir qui doit se taper le boulot. Parce qu'on peut tres bien prendre le même raisonnement, dire que le boulot de dev, c'est de fournir un code qui marche en respectant les contraintes de libs et que du coup, c'est à lui de se demerder avec la version packagé de la lib (celle qui est testé par les packageurs, dont on sait qu'elle va avoir les patchs de sécurité) plutôt que celle fraichement tagguée sur github (celle où la retro-comptabilité a été cassée sans faire expres, dont la conf par défaut à changé dont…).

            La question est donc : qu'est ce qui nous coute le plus cher, qu'est ce qui est le plus pérenne. Si tous tes services sont déjà dockerisé, chaque appli tourne avec la version qu'il lui faut, effectivement, c'est simple. Sinon, ca peut etre vachement compliqué et risqué de faire tourner plein de fois la meme lib à des versions différentes.

            Les développeurs ne testent pas ça ? Genre ils codent et commit sans jamais rien exécuté et toi tu dois inventer les procédures d'install/update/migration ? :)

            Parfois, on peut oublier qu'il n'y a pas que l'appli sur laquelle on est en train de bosser qui tourne sur la machine, mal mesurer un effet de bord etc. Le «Je comprend pas pourquoi les tests passent pas sur la plateforme de tests, en local ils marchent très bien» ça m'est arrivé, ainsi qu'aux collégues une paire de fois.

            • [^] # Re: Trollons

              Posté par . Évalué à 7. Dernière modification le 23/03/16 à 17:28.

              Parce qu'on peut très bien prendre le même raisonnement,[…]

              C'est souvent le cas et ça ne me choque pas tant qu'il s'agit de gérer les mises à jour du système et pas de figer le système (et donc de se garder un truc plus maintenu pendant des années).

              Pour le reste, je suis d'accord. Ce que je veux dire, c'est que l'image du pauvre sysadmin qui se fait malmener par les méchants dev qui font n'importe quoi sans avoir la moindre idée de ce qu'est ou ce que fait un sysadmin, c'est un peu surfait.

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

              • [^] # Re: Trollons

                Posté par . Évalué à 3.

                Pour le reste, je suis d'accord. Ce que je veux dire, c'est que l'image du pauvre sysadmin qui se fait malmener par les méchants dev qui font n'importe quoi sans avoir la moindre idée de ce qu'est ou ce que fait un sysadmin, c'est un peu surfait.

                Ah bon ? tu parles peut être de VRAI dev, car j'en connais beaucoup qui font semblant …
                Et je parle pas des dev qui oublie les 2 principes de bases : Fréquence et Volume
                Ou ceux qui vont modifier DIRECTEMENT dans la version en exploitation.

                Les tests c'est comme les freins sur les voitures c'est pour les lâches …

                Je caricature un peu … mais pas beaucoup

                • [^] # Re: Trollons

                  Posté par . Évalué à 4.

                  tu me rassures, je commencais à croire que j'étais le seul à bosser avec ce genre de dev.

          • [^] # Re: Trollons

            Posté par . Évalué à 10.

            Quelque soit le système de packaging, « si tout est packagé proprement », généralement ça reste propre ;-)

            A la différence que c'est mieux d'avoir 1 unique système de packaging plutôt que d'en gérer plusieurs qui sont en conflit entre eux.

            Les développeurs ne testent pas ça ? Genre ils codent et commit sans jamais rien exécuté et toi tu dois inventer les procédures d'install/update/migration ? :)

            Je ne met pas en conflit les sysadmin et les développeurs, je dis simplement que les deux ont des contraintes différentes. Un environnement de dev et de production c'est différent. Tu peux concevoir ton application de la meilleure manière possible, il y aura toujours potentiellement des problèmes en production car elle doit cohabiter avec d'autres, être soumise à des contraintes de sécurité (parefeu, selinux), de haute disponibilité, etc.

            Voilà pourquoi je n'aime pas les écosystèmes exotiques qui font cavalier seul, avec leurs propres dépendances, au lieu de se baser sur ce qui existe et ce qui est stable.

            Non, avoir un serveur propre c'est trivial et à la porté du premier venu. Tu télécharge l'iso de l'OS que tu veux, tu l'installe, tu débranche le câble réseau : t'as un serveur propre.

            Non. Ça c'est l'informatique des années 90 et on en paye le prix aujourd'hui (dette technique). Des choses installées sur le tas, non documentées, non pensées et sans visibilité sur l'avenir. Un bon sysadmin c'est quelqu'un qui a de l'expérience et connaît les choses à faire et à ne pas faire. Et accessoirement c'est lui qui se fait réveiller à 4h du matin quand la prod crashe, pas le développeur ;)

            Le boulot d'un sysadmin (ou d'un devops) c'est de maintenir un serveur qui fournis les services qu'on lui demande et oui ça demande de faire avec les services qu'on lui demande et oui il y a des fois où tu ne va pas pouvoir t'appuyer sur le travail de ta distrib (parce qu'il existe autre chose que SSH/(S)FTP/SMTP). Et oui ça demande de faire autre chose que juste la commande sortie de la doc de ta distrib'

            Oui, le sysadmin est le chef d'orchestre de l'infrastructure. Mais cela va plus loin que ça, par exemple installer un serveur Apache peut paraître simple (apt-get install apache2), mais ça ne l'est pas si on veut faire ça proprement (écriture de vhost de manière propre et sécurisée, dimensionnement, documentation, perspectives d'évolution…).

            Par contre t'es ultra outillé pour le faire quand même entre chef, puppet, ansible, salt, fabric et tout ce qui vient avec la mouvance des plateformes immutables (docker entre autre).

            Oui, ce sont des outils formidables si bien utilisés.
            Mais par exemple je ne laisserai pas Ansible mettre à jour libc6 si je sais que le serveur a des logiciels custom compilés à la main, trop dangereux.

            Donc oui c'est du travail, sinon ce ne serait pas payé ;)

            Pas assez malheureusement…

            • [^] # Re: Trollons

              Posté par (page perso) . Évalué à 1.

              Mais pourquoi ?… Pourquoi on ne peut pertinenter plusieurs fois ? :'(

              http://gregr.fr

        • [^] # Re: Trollons

          Posté par (page perso) . Évalué à 3.

          Si tu vas par là, un bon sysadmin il a:
          - Une documentation complète des projets
          - Une documentation complète des serveurs

          Sur une version stable de ta distro, tu n'auras pas d'upgrade de libc6 qui va casser tes propres builds.

          Si tu fais une mise à jour de ta distro vers une nouvelle version majeur, dans le monde du travail(je ne parle pas d'administrer son serveur perso), tu fais au minimum une préproduction (et mieux une qualification).

          Tu ne fais pas un dist-upgrade sur un serveur de prod comme un porc.

          • [^] # Re: Trollons

            Posté par . Évalué à 2.

            Je tape sur les devs, mais force est de constater que j'ai vu des sysadmins faire ce genre de choses … voire pire du style débrancher à chaud un des deux disques mirroir d'un RAID, et considerer le disque débranché comme la sauvegarde en cas de pépin lors de l'intervention sur la BDD …

    • [^] # Re: Trollons

      Posté par (page perso) . Évalué à 6.

      C'est marrant de parler de Docker comme un cache-misère, moi si un sysadmin décide de faire de l'ingérence dans les dépendances de mon application, je lui dirais que je n'ai besoin que de Docker. Je résous le problème en faisant de l'ingérence dans les outils qu'il devra utiliser quoi ;-)

      Sans attaque personnelle, je suis curieux de savoir dans quel domain tu es sysadmin. De mon point de vu vouloir gérer les dépendances à partir des paquets de la distrib est peine perdue sortie de C/C++ et (j'imagine, merci de me corriger si ce n'est pas le cas) Java.
      Les autres langages fournissant un outil de gestion des dépendances adapté, cela ne sert à rien de dupliquer les efforts pour avoir un résultat moins bon, examples:

      • deux projets ont des dépendances en version différentes, comment faire via apt-get pour que chaque projet utilise la bonne version de la lib ? Pour résoudre ce problème npm et composer installent dans le répertoire du projet, pip a les virtualenv etc.

      • Pour un projet en python/ruby/php/js une majorité des dépendances ne sont pas packagées dans la distrib, il faut tout re-écrire dans le projet ? (bonjour l'explosion de la complexité et de maintenance…) ou bien tout copier en dur dans le projet ?

      Concernant le problème de disparition d'une dépendance dont parle l'article, Docker résous justement ce problème : il suffit de construire l'image du projet à partir d'une image contenant les dépendances et le tour est joué !

      • [^] # Re: Trollons

        Posté par . Évalué à 7.

        De mon point de vu vouloir gérer les dépendances à partir des paquets de la distrib est peine perdue sortie de C/C++ et (j'imagine, merci de me corriger si ce n'est pas le cas) Java.

        Pour Java, il ne faut surtout JAMAIS vouloir gérer les dépendances par le système en java. JAMAIS, même pas un peu et il n'y a pas d'exception ou de cas particulier.

        Les dépendances sont gérer par ce que l'on appel un classpath. C'est une liste de dossiers ou d'archives jar (des zip) qui sont chargées au démarrage de l'application. Au cas où ça aurait échappé en première lecture, qui sont « chargées au démarrage de l'application ». Donc plus tu en as plus c'est long et lent (le chargement du classpath c'est ce qui consomme le plus au démarrage de la JVM), mais c'est surtout un bon moyen d'injecter une porte dérobée dans une application.

        Donc non, pas de gestion de dépendance système wide en java. Personnellement je préfère fournir un « fat jar » qui inclue les dépendances. Oui ça empêche les admin de faire une mise à jour d'une dépendance sans en parler au dev (comme c'est dommage).

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Trollons

        Posté par . Évalué à 10.

        C'est marrant de parler de Docker comme un cache-misère, moi si un sysadmin décide de faire de l'ingérence dans les dépendances de mon application, je lui dirais que je n'ai besoin que de Docker. Je résous le problème en faisant de l'ingérence dans les outils qu'il devra utiliser quoi ;-)

        Ce n'est pas qu'un cache misère. Bien sûr que Docker c'est très bien, le problème c'est que pour beaucoup c'est un moyen de packager une application + ses milliards de dépendance qui vont avec sans se faire chier à documenter. Résultat on exécute le tout mais on ne sait pas comment ça marche, et le jour où ça crashe (à 3h du matin le dimanche bien sûr) on appelle le sysadmin en catastrophe pour tout remonter. Mais vu que l'install n'est pas documentée (c'était plus simple de fournir un unique container Docker) c'est la galère.

        Sans attaque personnelle, je suis curieux de savoir dans quel domain tu es sysadmin. De mon point de vu vouloir gérer les dépendances à partir des paquets de la distrib est peine perdue sortie de C/C++ et (j'imagine, merci de me corriger si ce n'est pas le cas) Java.

        Non ce n'est pas peine perdue, à ma connaissance Debian package de tas d'applications capables d'utiliser les dépendances des mêmes dépôts ? Cette mode de vouloir outrepasser les versions de la distribution et avoir du frais est à mon sens récente et est arrivée avec node.

        deux projets ont des dépendances en version différentes, comment faire via apt-get pour que chaque projet utilise la bonne version de la lib ? Pour résoudre ce problème npm et composer installent dans le répertoire du projet, pip a les virtualenv etc.
        Pour un projet en python/ruby/php/js une majorité des dépendances ne sont pas packagées dans la distrib, il faut tout re-écrire dans le projet ? (bonjour l'explosion de la complexité et de maintenance…) ou bien tout copier en dur dans le projet ?

        Ma réponse va sembler simpliste mais : tu code ton appli pour qu'elle tourne sur Debian 8 et c'est tout. N'utilise pas de dépendances externes ou en version trop récente. Cet enfer de dépendances est peut-être justement due au fait que tout le monde veut aller trop vite et considère que le problème vient des distributions ? Moi je vois ça dans l'autre sens, on code sur des ecosystèmes inexistants ou exotiques et on fait du forcing/bidouillage pour caser ça en production.

        • [^] # Re: Trollons

          Posté par (page perso) . Évalué à 4.

          Ma réponse va sembler simpliste mais : tu code ton appli pour qu'elle tourne sur Debian 8 et c'est tout. N'utilise pas de dépendances externes ou en version trop récente.

          Personnellement ma réponse à la problèmatique est exactement inverse : installer pour chaque projet ses dépendances via le gestionnaire de la techno utilisé et ne surtout pas utiliser les paquets du système.

          • Dépendances minimes du point de vu du sysadmin : l’interpréteur du langage + le gestionnaire de dépendances (bonus combo pour python 3 qui fourni CPtyhon, pip et virtualenv de série dans toutes les installations). Parfois un paquet en plus dans le cas d'un module binaire (par exemple pySSL aura besoin de libopenssl installé) mais c'est plutôt rare

          • Agnostique vis-à-vis du système : la prod peut être sur Debian, les dev répartis entre Ubuntu et Mac et demain on peut migrer sur Heroku, personne n'aura de soucis

          • Isolation des dépendances entre les applications : pas de risque de se retrouver avec une maj d'un dépendance pour l'application A qui casse l'application B, pas non plus de risques de se retrouver avec des dépendances implicites qui on été installées par d'autre applications

          D'ailleurs en parlant d'Heroku, voir la partie dépendances de leur manifeste sur le concept de "12 factor app"

        • [^] # Re: Trollons

          Posté par . Évalué à 4.

          Mais vu que l'install n'est pas documentée (c'était plus simple de fournir un unique container Docker) c'est la galère.

          1. WTF ? Tu va faire quoi ? Redéployer à l'arrache sur un environnement différent de celui sur le quel ça a était testé ? « Ah c'était dans du docker ? c'est pas grave je redéploie bare metal sur ma distrib' qui va bien et j'imagine que ça tourne ».
          2. Le dockerfile est une documentation exécutable qui est largement plus fiable qu'un document difficile à maintenir et à tester.
          3. En tant que dev, je me suis déjà fait appeler à 1 ou 2h du mat'. Contrairement au sysadmin, c'est pas dans mon contrat.

          Cette mode de vouloir outrepasser les versions de la distribution et avoir du frais est à mon sens récente et est arrivée avec node.

          JS a bon dos. cpan, gem, pip,… sont plus vieux que node. Pareil pour les trucs comme maven.

          Ma réponse va sembler simpliste mais : tu code ton appli pour qu'elle tourne sur Debian 8 et c'est tout.

          Il y a rien sur Debian (comme sur n'importe quelle autre distrib'). Dès que tu as un besoin un peu pointu ta dépendance tu l'a pas. Rencontré un bug ou avoir une fonctionnalité manquante dans une lib ça arrive aussi très fréquemment. Il y a un moment où tu fais un choix, entre coder en plus pour te contraindre à une plateforme donnée soit utiliser quelque chose de plus récent. Mon choix est très vite fait et si l'exploitant n'est pas content je me plis à ce qu'il souhaite : je lui construit un paquet de la distrib', crée un playbook, un conteneur,… Tout ceux que j'ai rencontré ne voulaient aucune de ses solutions (soient il ne connaissent pas soit ils ne veulent pas apprendre).

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: Trollons

          Posté par (page perso) . Évalué à 10.

          Ma réponse va sembler simpliste mais : tu code ton appli pour qu'elle tourne sur Debian 8 et c'est tout. N'utilise pas de dépendances externes ou en version trop récente. Cet enfer de dépendances est peut-être justement due au fait que tout le monde veut aller trop vite et considère que le problème vient des distributions ?

          Sérieusement, il faut évoluer là. On n'est plus dans les années 90 où la plupart des softs étaient en C/C++ avec des dépendances binaires, donc des dépendances fortes avec les systèmes.

          Alors peut-être que ton quotidien consiste à déployer majoritairement des applis C++, mais il n'y a pas que les applis à dépendances binaires dans la vie.

          Un projet Node, PHP, python ou autre techno n'a pas de dépendances binaires, des trucs à compiler fortement liés aux systèmes. La seule dépendance qu'ils ont avec le système, c'est le paquet du runtime. Et encore.. un projet réalisé avec PHP 5.3 peut très bien fonctionner avec 5.6 par exemple.

          Un programme en NodeJS ou PHP (avec Composer), a toutes ses dépendances avec lui (répertoire vendor/ pour PHP). Sérieusement, qu'est ce que ça peut te faire toi, que ce programme ait ses dépendances avec lui ? En quoi est-ce différent d'un programme dans lequel le développeur aurait développé ses propres libs plutôt que de réutiliser l'existant ? Dans ce cas là aussi, tu forcerais le développeur a mettre à la poubelle ses libs et le forcer à utiliser PEAR ?

          De mon point de vue, ce n'est pourtant pas de ta responsabilité.

          Je comprend ton point de vue pour ce qui est des projets développés en C/C++ non linkés statiquement, parce que oui, là, effectivement, il y a une forte dépendances avec le système, et que ça peut foutre la merde.

          Mais pour du node, du php ou autre langage interprété, je ne comprend pas ta réaction. Je n'ai jamais eu à faire à un admin-sys avec de telles exigences, qui sont d'ailleurs pour moi totalement infondées. Quand je travaille avec un admins-sys en général, il m'impose une version de PHP, une version de base de donnée, une version de rabbit mq etc, bref, une version des outils qui gravitent autour de l'appli. Ce que je peux comprendre parce qu'il n'a pas envie d'avoir un parc hétéroclite et que tous ses serveurs sont en Debian 8 par ex. Va donc pour du PHP de telle version, et je fais avec.

          Mais de là à m'imposer à ne pas utiliser des libs externes, non fournis en général par le système, mais par un système de package comme Composer ou Npm, alors là, j'hallucine, je ne comprend pas. Je fais comment alors ? je réécris tout from scratch ? Je ré-invente la roue tous les jours ? Bonjour les coûts et les temps de développements…

          D'ailleurs, je comprend encore moins ta réaction puisque pour moi, moins de dépendances avec le système, c'est moins de souci. Tu peux faire cohabiter plusieurs applis ayant des dépendances avec des version différentes, sur un même serveur. Alors que faire cohabiter deux applis PHP qui reposent sur une version de PEAR différente (installée via le système), c'est mission quasi impossible. Et c'est d'ailleurs la raison pour laquelle PEAR n'a jamais vraiment percé, jamais été apprécié par les développeurs. On se retrouve avec des libs vieillottes, pas à jour, donc avec des fonctionnalités manquantes, et donc à devoir réinventer la roue sans cesse. Et si par malheur on voulait faire un upgrade des libs PEAR, il y a de fortes chances que ça casse les vieilles applis déjà en place. Pas cool pour un admin. Alors que depuis l’avènement de Composer, et donc la possibilité d'installer des libs à l’intérieur du projet même, sans conséquence pour le reste du système et des autres applis, c'est bien plus simple d'un point de vue administration (ou alors quelque chose m'échappe), et bien plus simple pour le développeur.

          L'évolution de l'informatique converge vers la minimisation des dépendances : autonomie des applications, autonomie des services. Le succès de docker en est l'expression la plus forte. Mettre tout sur la même machine, sur le même système, c'est fini, terminé : c'est trop de contraintes pour tout le monde, trop compliqué pour faire évoluer les applications etc…

          En tant qu'admin sys, tu devrais t'en réjouir… À moins que tu n'aimes pas les changements qui s'opèrent dans ton métier ? Il se transforme, il passe de la gestion pure et dure d'une machine et de son OS à la gestion d'un Cloud, de containers, de micro-services et j'en passe. Nouvelles méthodes, nouvelles façon de voir les choses. Tout ça pour permettre d'être plus réactif aux demandes des utilisateurs, de pouvoir chipper une nouvelle fonctionnalité rapidement, sans à se poser de question "est ce que ça ne va pas casser l'appli Y?", ou encore "comment je fais pour implémenter cette fonctionnalité parce que l'admin-sys veut pas que j'utilise telle lib, qui pourtant me permettrait de coder ça en 1 heure ?" .

          Fournir et faire évoluer rapidement un service suite à des demandes utilisateurs, c'est le but de tous services informatiques non ? (c'est le seul truc qui n'a pas changé ça ;-)

          • [^] # Re: Trollons

            Posté par (page perso) . Évalué à 3.

            D'ailleurs, "npm install -g" suxx, du coup.

          • [^] # Re: Trollons

            Posté par . Évalué à 3.

            En tant qu'admin sys, tu devrais t'en réjouir…

            Je vais peut être parler à sa place, mais en tant qu'admin sys ça devrait lui faire peur. Que se passe t'il si le module intégré link vers une version particulière et que cette dernière est trouée? Comme chaque appli vient avec ses propre dépendances il risque de se retrouver avec 15 version différente avec 12 failles différentes.

            Il ne faut pas décorner les boeufs avant d'avoir semé le vent

            • [^] # Re: Trollons

              Posté par (page perso) . Évalué à 5.

              La meme chose que si le dev n'a pas utilisé et lib et codée lui meme une faille ?

            • [^] # Re: Trollons

              Posté par . Évalué à 5.

              En quoi est-ce que c'est au sysadmin de jouer avec les dépendances de l'application ? Si tu as une telle faille, ça revient forcément au développeur de faire une nouvelle livraison. On ne peux pas reprocher d'un coté au développeur de ne pas correctement gérer les dépendances de son application et de l'autre faire ce que tu veux avec ces même dépendances.

              Lorsqu'il s'agit de bibliothèques système wide oui le sysadmin as tout pouvoir pour mettre à jour en suivant ce que lui propose l'OS.

              Quand tu requière le support du développeur (que ce soit pour un projet spécifique ou via un éditeur plus ou moins gros), tu te met à dos au mieux les développeurs au pire le contrat qui les lie à toi.

              De la même manière que ça crispe les adminsys de voir des utilisateurs installer leur « propres » logiciels, ça crispe les développeurs de voir le sysadmin retoucher n'importe quoi dans l'application.

              Soit tu fais du devops et il n'y a pas de frontière dev/sysadmin, soit il vaut mieux rester dans son domaine de compétence et communiquer avant de jouer ainsi.

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

            • [^] # Re: Trollons

              Posté par (page perso) . Évalué à 7.

              Je dirais que le sysadmin n'a pas à vérifier les dépendances de chaque appli, ce n'est à mon avis pas son rôle. Parce que dans ce cas là, il vérifie aussi le code de toutes les applis que les devs de sa boite font, sans parler de tous les outils qu'il doit installer sans passer par apt (bah oui, il y a plein d'outils que l'on peut avoir besoin absolument mais qui ne sont pas les dépôts de la distro). Il n'a alors jamais fini.

              Tout ce qui est problématique de sécurité dans le code, je dirais que ce serait plutôt à l'équipe QA de vérifier tout ça, quand ce n'est pas aux développeurs de le faire (encore faut-il avoir une politique de sécurité).

              Le sysadmin par contre, son rôle, IMHO, est de limiter les dégâts en cas d'éventuels attaques via des trous de sécu. C'est à dire cloisonner les applis (container par ex), ne les laisser accéder que ce à quoi elles ont droit d'accéder (firewall &cie), et mettre en place du monitoring pour détecter les comportements inadéquates.

              Et si il découvre qu'il y a effectivement des problèmes, voir qu'il découvre à ses heures perdues une faille dans un paquet d'une appli, il fait comme pour tout logiciel qu'il installe sur son infra : il fait passer l'info en upstream (à Debian si c'est un paquet debian, aux dev de sa boite si c'est une appli interne, etc..).

              Enfin bon, c'est en tout cas la manière dont je vois les choses.

        • [^] # Re: Trollons

          Posté par (page perso) . Évalué à 7.

          Non ce n'est pas peine perdue, à ma connaissance Debian package de tas d'applications capables d'utiliser les dépendances des mêmes dépôts ? Cette mode de vouloir outrepasser les versions de la distribution et avoir du frais est à mon sens récente et est arrivée avec node.

          C'est parceque tu vois ça avec tes yeux d'utilisateur de Debian, mais regardons le problème du point de vue du programmeur JavaScript. Ce programmeur fait partie d'une communauté qui se retrouve autour d'un langage mais travaille dans un environnement hétérogène. Ainsi les développeurs JavaScript utilisant des dépendances externes se retrouvent confrontés aux problèmes où le binding qu'ils écrivent ne marchent pas sous la distribution bla bla Linux parceque la zlib y est en version 2.0 tandis que sur leur système glop glop Linux elle est en version 2.0.1 – et que des différences subtiles créent des problèmes difficile à reproduire. L'introduction d'un système de packages ad-hoc permet donc à cette communauté de se réunir autour d'un éco-système relativement homogène, et d'introduire une abstraction pour traiter les cas particuliers liés aux différents systèmes.

          Cette stratégie répond donc à un problème bien concret qu'elle résout – non sans amener son propre lot de problèmes, mais apparemment il n'y a aucune solution qui permet de gagner sur toute la ligne, on est donc amené à faire des compromis en fonction de ses priorités.

          • [^] # Re: Trollons

            Posté par . Évalué à 10.

            De toute façon l'autre solution c'est de faire comme go : on compile statiquement et on rend littéralement impossible une gestion système wide des dépendances. On empêche aussi le sysadmin de toucher aux dépendances. C'est une manière violente de faire un gros fuck au monsieur qui veut une gestion « propre » des dépendances :)

            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: Trollons

      Posté par . Évalué à 2.

      Rien n'est jamais packagé (par la distribution) dans la bonne version

      J'essaie de comprendre ce qu'il est bancal,
      le semver qui te fait changer de version ? => shrinkwrap ?

      Vu mon support de samba sur fedora (truc rygel qui me balance des c**** dans journald et va te lever tôt pour corriger le bouzin) je suis bien content qu'il ne s'occupe pas de TOUS les paquets….

  • # npm, comment dire...

    Posté par (page perso) . Évalué à 10. Dernière modification le 23/03/16 à 12:04.

    on peut se poser la question de la fiabilité des projets JavaScript qui dépendent de centaines de modules npm

    On peut se poser aussi la question d'utiliser npm tout court, qui est un système de paquet complètement pourri de mon point de vue, où, pour un même projet, on se voit à télécharger 20 versions du même paquet parce que le projet dépend de 40 paquets qui utilisent 20 versions différentes du même paquet (sans compter les autres versions de paquets similaires, parce que bien entendu, ces 40 paquets qui ont besoin d'une même fonctionnalité, ne vont pas utiliser la même lib qui propose cette fonctionnalité).

    L'installation de certains outils utilisant npm est hallucinant en terme de temps de téléchargement et d'installation. Sans compter que, puisque qu'il y a 20 versions d'un même paquet, alors on se retrouve avec ces 20 versions en mémoire et du code similaires exécutés bien entendu 20 fois au chargement (pour une seule instance de l'outils).

    C'est un gachi de ressources hallucinant, tant à l'installation (bande passante &co, même si npm gère un cache), qu'à l'exécution.

    Et je ne parle pas des nombreux paquets qui n'ont rien à voir avec JS, mais qui sont dans npm parce que leurs auteurs ont trouvé sympa de pouvoir installer leurs logiciel via npm. WTF.

    PS: corollaire du problème de télécharger 20 versions d'un même paquet : les statistiques de téléchargement sur npmjs.org sont totalement bidons et ne veulent rien dire au final.

    • [^] # Re: npm, comment dire...

      Posté par (page perso) . Évalué à 5.

      Et tu ne parles même pas de "npm search" qui utilise un temps d'exécution calamiteux.

    • [^] # Re: npm, comment dire...

      Posté par . Évalué à -1.

      C'est un gachi de ressources hallucinant, tant à l'installation (bande passante &co, même si npm gère un cache), qu'à l'exécution.

      Je pense pas que le fait d'utiliser 50Mo de ram en plus soit un argument recevable de nos jours.
      Le problème est plutôt "est-ce que ça passe à l'échelle ou pas ? jusqu'à combien d'utilisateurs en parallèle ? combien ça coûte en temps de développement / admin sys d'optimiser ? pour quel bénéfice ?".

      Si tu passes du temps à optimiser des dépendances pour augmenter les performances de 2% pour un cas particulier, je pense sincèrement que c'est inutile (enfin c'est intéressant pour moi mais je vais pas prendre le risque de casser des applis au travail pour ça).
      Si tu passes du temps pour monter d'un ordre de grandeur dans le passage à l'échelle, oui c'est intéressant si tu en as l'utilité…

  • # Dépendances

    Posté par . Évalué à 8.

    on peut se poser la question de la fiabilité des projets JavaScript qui dépendent de centaines de modules npm.

    On peut se poser la question pour un projet quelque soit le langage quand les dépendances augmentent.

    Un projet en C aura tout autant de problème que celui en JS si l'une de ses dépendances n'est plus maintenue, casse la compatibilité, a une faille de sécurité, etc

    Le undeploy d'une dépendance n'est qu'un cas particulier de ces problèmes.

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: Dépendances

      Posté par (page perso) . Évalué à 9.

      Oui, mais le risque est démultiplié en javascript pour 2 raisons :

      • La bibliothèque standard est incroyablement pauvre et les modules npm sont souvent utilisés en grande quantité pour compenser ;
      • Npm2 peut installer plusieurs fois la même dépendance dans des versions différentes (npm3 corrige ça mais a d'autres problèmes).
      • [^] # Re: Dépendances

        Posté par . Évalué à 3.

        La bibliothèque standard est incroyablement pauvre et les modules npm sont souvent utilisés en grande quantité pour compenser ;

        Je connais très mal node et je me demandais pourquoi la fonction n'utilisait pas plus les méthodes de String.

        Si j'essaye :

        function leftpad (str, len, ch) {
            return ch.repeat(len-str.length).concat(str);
        }
        

        Ça marche avec gjs (basé sur SpiderMonkey que je suis plus habitué à utiliser) mais node ne connait pas repeat. En fait, en regardant plus en détails, j'ai l'impression que new String dans node donne un objet différent des chaines primitives et aucun n'a les méthodes standard de String. Pourquoi ce manque ? Ou c'est moi qui confond des extensions de SpiderMonkey avec le standard ?

        La bibliothèque standard pauvre n'est-elle pas plus un problème propre à node plutôt qu'à javascript ? Un logiciel utilisant javascript devrait fournir les classes de bases (Object, Function, String, Array, Math, …) et d'autres propres au contexte (par exemples les objets window et document dans un navigateur web, node a console et, j'imagine, quelques autres).

        • [^] # Re: Dépendances

          Posté par (page perso) . Évalué à 3.

          Pourquoi ce manque ? Ou c'est moi qui confond des extensions de SpiderMonkey avec le standard ?

          Non c'est juste que certaines versions de Node (entre NodeJS v4.0+, la serie NodeJS v0.12 toujours maintenue et Io.js, j'y perd mon latin) utilise une vieille version de V8. La fonction repeat n'est apparu à priori que dans Chrome 41, ce qui correspond à V8 4.1. Or V8 4.1 n'est utilisé que depuis io.js v1.0.3 et donc NodeJS v4.0.0. Donc il y a à peine plus d'un an.

          Alors que Spidermonkey l'implémente depuis Firefox 24, c'est à dire septembre 2013.

      • [^] # Re: Dépendances

        Posté par (page perso) . Évalué à 6.

        Est-ce que je dois comprendre que tu serais prêt à créer un grand mouvement pour l'adoption d'un meilleur langage de programmation web

        • Pensé "batteries included" (piles fournies),
        • Yeux reposés, optimisé pour l'expressivité, la durabilité (facilité de lecture),
        • Tout en épargnant au développeur pressurisé la charge cognitive inutile du comptage d'accolades ouvertes,
        • Heureusement répandu et idéal en premier langage de programmation,
        • Opiniâtre parce qu'il a de bonnes raisons d'être comme il est (évoluant quand ça n'est pas le cas),
        • Nonobstant, qui fait repousser les cheveux et gagner au loto ?

        Certes tu n'es peut-être pas encore convaincu de ta mission, mais c'est un détail, car elle est grande et porte en elle un espoir pour le futur du monde large toilé !

        • [^] # Re: Dépendances

          Posté par . Évalué à 6.

          Pensé "batteries included" (piles fournies),
          Yeux reposés, optimisé pour l'expressivité, la durabilité (facilité de lecture),
          Tout en épargnant au développeur pressurisé la charge cognitive inutile du comptage d'accolades ouvertes,
          Heureusement répandu et idéal en premier langage de programmation,
          Opiniâtre parce qu'il a de bonnes raisons d'être comme il est (évoluant quand ça n'est pas le cas),
          Nonobstant, qui fait repousser les cheveux et gagner au loto ?

          C'est python ça, non ?

          • [^] # Re: Dépendances

            Posté par . Évalué à 1.

            Non, surtout pas. Python est le VB du libre. Une horreur. Les adorateurs du Serpent pensent que ce langage est lisible parce qu'il force à indenter, mais c'est une illusion. Python est loin d'être lisible (surtout quand tu te mets à mettre au beau milieu de ton code des paradigmes fonctionnels : ça casse l'homogénéité et la fluidité de la lecture). Il y a d'autres problèmes avec Python que je ne détaillerai pas parce qu'il est tard, mais pour donner une idée, la façon dont il t'oblige à faire un print de ligne sans retour chariot est siplement abominable, et résume bien l'esprit du langage.

            • [^] # Re: Dépendances

              Posté par . Évalué à 7.

              print(text, end=''), il y a pire non ? Surtout que personnellement, je fais bien plus souvent des print avec retour de chariot que sans, donc j'apprécie le fonctionnement par défaut. Après, forcément, si on utilise une version d'il y a plus de 5 ans…

            • [^] # Re: Dépendances

              Posté par (page perso) . Évalué à 4.

              Si Python est difficile à lire… On peut avoir un exemple de langage simple à lire ?

              Et pour le print sans retour charriot, il suffit de mettre une virgule à la fin du print en python2

              print 'python le fait',

              Et il y a l'argument "end" qu'on peut spécifier en python3 (oui, il ont amélioré la lisibilité ;-)

              print("Python3 le fait plus mieux ", end="")

              Bref si tu en es à ce genre d'arguments c'est que tu ne connais pas Python.

              • [^] # Re: Dépendances

                Posté par . Évalué à 2.

                Comment est-ce qu'on minifie du code python ? :)

                Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                • [^] # Re: Dépendances

                  Posté par (page perso) . Évalué à 7.

                  Il suffit de prendre le code "compilé" (le bytecode généré à la première exécution) :)

          • [^] # Re: Dépendances

            Posté par (page perso) . Évalué à 7.

            Bonne nouvelle à propos de python!

            Left-pad est enfin sur pypi: https://pypi.python.org/pypi/left-pad/

          • [^] # Re: Dépendances

            Posté par (page perso) . Évalué à 3.

            Non, c'est Elm. Indiscutablement.

        • [^] # Re: Dépendances

          Posté par . Évalué à 3.

          C'est Ruby, c'est ça ? :p

          "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

        • [^] # Re: Dépendances

          Posté par (page perso) . Évalué à 5.

          Oui, j'aimerais bien voir un autre langage disponible dans les navigateurs (ou même plusieurs via WebAssembly). Côté serveur, la question ne se pose pas trop, on a déjà le choix d'utiliser Go, Ruby, Python, Erlang, Elixir et plein d'autres langages plus sensés que le JS.

          En ce moment, je regarde du côté d'Elm. Ça a l'air pas mal mais je ne connais pas encore assez pour dire s'il répond aux critères. Le langage est jeune et a encore des défauts de jeunesse, mais on sent qu'il a du potentiel.

          • [^] # Re: Dépendances

            Posté par (page perso) . Évalué à 4.

            Elm :

            Pensé "batteries included" (piles fournies),

            Pas check. L'écosystème d'Elm est encore trop jeune et trop maigre :( On arrive assez vite aux limites. Mais c'est en pleine progression actuellement.

            Yeux reposés, optimisé pour l'expressivité, la durabilité (facilité de lecture),

            Check

            Tout en épargnant au développeur pressurisé la charge cognitive inutile du comptage d'accolades ouvertes,

            Mega-check

            Heureusement répandu et idéal en premier langage de programmation,

            Pas check. La courbe d'apprentissage de Elm est plutôt raide, quoiqu'en disent ses promoteurs. Pas tant dans le langage dont on fait assez vite le tour, mais dans le fait de prendre de nouveaux réflexes et de s'adapter aux contraintes d'un langage purement fonctionnel.

            Opiniâtre parce qu'il a de bonnes raisons d'être comme il est (évoluant quand ça n'est pas le cas),

            Check

            Nonobstant, qui fait repousser les cheveux et gagner au loto ?

            Je sais pas si on a un Nonobstant ici, mais j'ai les cheveux de la barbe qui poussent depuis que je fais du Elm, quant à gagner au loto, faudrait déjà que je joue, mais je suis sûr que je gagnerais. Mais bon, j'ai déjà un ordinateur et un fauteuil confortable, de quoi aurais-je donc besoin de plus ?

    • [^] # Re: Dépendances

      Posté par . Évalué à 10.

      Un projet en C aura tout autant de problème que celui en JS si l'une de ses dépendances n'est plus maintenue, casse la compatibilité, a une faille de sécurité, etc

      Non mais t'as vu un peu le code en question, je veux bien que le dev soit féneant, qu'il ne veuille pas réinventer la roue, mais utiliser des modules tiers pour un traitement de chaîne aussi basique, c'est à pleurer. C'est de l'ordre du snippet ici vu qu'il manque de la doc, des tests et que ça ne couvre qu'un cas de figure.

      Le truc, c'est que c'est récurrent en .js. des milliers de petits modules de 10 lignes minimum.

      Il faudrait calmer la fougue de ces jeunes devs .js qui se prennent pour les rois du monde et affiche du CTO par-ci et du Co-Founder par là pour des trucs triviaux.

      • [^] # Re: Dépendances

        Posté par . Évalué à 4.

        Non mais t'as vu un peu le code en question[…]

        Ça n'a rien avoir avec le code. Tu as une dépendance vers disons, OpenSSL, ta distrib' décide de virer ta lib, soit tu l'a téléchargée avant soit t'es KO.

        Ce dont tu parle c'est de la multiplication des dépendances liés, comme dis au-dessus, à la pauvreté de la lib standard. Pour pallier à ça je crois que les bibliothèques et les frameworks intègrent chacun un set de fonction de ce genre. C'est palliatif.

        C'est de l'ordre du snippet ici vu qu'il manque de la doc, des tests et que ça ne couvre qu'un cas de figure.

        Il aurait écris des Gio de doc et fait 100 millions de tests le undeploy aurait eu précisément la même conséquence.

        Il faudrait calmer la fougue de ces jeunes devs .js qui se prennent pour les rois du monde et affiche du CTO par-ci et du Co-Founder par là pour des trucs triviaux.

        Vu les projets qui ont cassé, je ne m'aventurerais pas à affirmer que ce sont des « jeunes devs fougueux ». Par contre que JS s'affirme comme un langage de très haut niveau avec une bibliothèque standard plus complète, ça ne me choquerait pas. Il manque probablement un projet à la boost qui soit généraliste et qui ai pignon sur rue.

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: Dépendances

          Posté par . Évalué à 3.

          J'ai bien compris ce sur quoi vous argumentiez.

          Mais je ne pense pas que npm aurait viré du jour au lendemain un truc comme ssl si ssl.com venait à les ennuyer.

          Il faudrait calmer la fougue de ces jeunes devs .js qui se prennent pour les rois du monde et affiche du CTO par-ci et du Co-Founder par là pour des trucs triviaux.

          Vu les projets qui ont cassé, je ne m'aventurerais pas à affirmer que ce sont des « jeunes devs fougueux ».

          Evidemment qu'il s'agit d'un troll de ma part mais justement, cela étant, peu importe la taille du projet en question, ils ont quand même eu recourt à un module trivial de qualité médiocre.

          • [^] # Re: Dépendances

            Posté par . Évalué à 1.

            Tu base tout sur la qualité/l'image ou non du module, pour moi ce genre de réflexion s'approche du « ça n'arrive qu'aux autres ».

            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: Dépendances

      Posté par . Évalué à 4.

      Au moins en C, tu as une librairie standard.

      Quand on voit ce que font ces 11 lignes de codes, on se demande quand même si le soucis c'est qu'il ne faille pas installer un module pour faire un strcmp quoi…

      • [^] # Re: Dépendances

        Posté par (page perso) . Évalué à 2.

        Quand on voit que ces 11 lignes n'ont rien à voir avec strcmp, on se demande quand même si le souci c'est pas les développeurs C, ou leur condescendance au moins.

        • [^] # Re: Dépendances

          Posté par . Évalué à 9.

          Surtout que vanter la bibliothèque standard du C, c'est un peu l'hôpital qui se fout de la charité… On parle bien du langage où les fonctions de traitement de chaîne les plus connues posent des problèmes de sécurité ? Où il n'y a pas de conteneur associatif en standard ? Où la prise en charge des textes non-ASCII est pourrie ?

      • [^] # Re: Dépendances

        Posté par . Évalué à 3.

        Tu la trouve où leftpad dans le norme C ? (choisie la version que tu veux, y compris celle en préparation si ça peut t'aider :) )

        Sachant que le code C équivalent est presque identique (on explicite plus les types et on fait une allocation mémoire de la bonne taille plutôt que de concaténer).

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: Dépendances

          Posté par . Évalué à 6. Dernière modification le 24/03/16 à 09:40.

          Mouai…, on va dire si je comprend bien a quoi sert la fonction, c'est faire des affichages avec de l'indentation. Alors oui il n'y a pas la même fonction pour faire ça en C, mais il me semble que les *printf sont utilisés pour faire ça dans plein de logiciel open source. Alors certes il y a certainement des helpers, c'est moins optimisé, mais pas besoin d'importer une dépendance. Bref, je suis pas sur de la pertinence de comparer les fonctions de base fournies pas les langages. On va dire que c'est plus l'état d'esprit et la "complexité" d'ajouter une bibliothèque qui fait que personne n'ajouterait une dépendance pour ça en C.

        • [^] # Re: Dépendances

          Posté par . Évalué à 5.

          #include <stdio.h>
          int main() {
              printf("[%*s]\n", 20, "right") ;
              printf("[%-*s]\n", 20, "left") ;
          }

          produira:

          [               right]
          [left                ]
          

          Limité a l'espace pour le caractère de remplissage, variantes sprintf/snprintf pour travailler en mémoire sans affichage, avec toutes les blagues habituelles en cas de dépassement du buffer.

          • [^] # Re: Dépendances

            Posté par . Évalué à -3.

            Presque c'est snprintf qui fait le boulot. Le padding ça ne sert pas qu'à l'affichage.

            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: Dépendances

          Posté par (page perso) . Évalué à 4.

          Leftpad en C est là : https://github.com/lovenunu/leftpad-c

      • [^] # Re: Dépendances

        Posté par (page perso) . Évalué à 3.

        Oui, ce genre de module montre la faiblesse d'une lib standard.

        Si ça peut rassurer, String.padStart et String.padEnd arrivent dans ES7

        https://github.com/tc39/proposal-string-pad-start-end
        https://bugzilla.mozilla.org/show_bug.cgi?id=934776

  • # Quitte à partir dans tous les sens ...

    Posté par . Évalué à 1.

    Moi ce que ça m'évoque, c'est que ledit Azer, outre sa susceptibilité plus ou moins mal placée, serait bien inspiré de lire ceci:
    http://www.amazon.fr/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882

    • [^] # Re: Quitte à partir dans tous les sens ...

      Posté par (page perso) . Évalué à 2.

      Il nous parle d'opensource mais ses projets ne comportent pas de mention de la licence utilisé surtout.

      M'enfin quand même, pouvoir dé-publier un truc publié de longue date sur npm ça me semble surtout une anti-fonctionnalité. Ce qui n'empêche pas que je comprends tout à fait la réaction du type face à ces menaces sur le droits des marques (rien à voir avec le droit d'auteur ou copyright d'ailleurs)

      • [^] # Re: Quitte à partir dans tous les sens ...

        Posté par (page perso) . Évalué à 8.

        Il nous parle d'opensource mais ses projets ne comportent pas de mention de la licence utilisé surtout.

        Si, la licence est mentionnée (même si c'est relativement bien caché). C'est du WTFPL.

        M'enfin quand même, pouvoir dé-publier un truc publié de longue date sur npm ça me semble surtout une anti-fonctionnalité.

        Oui, cette fonctionnalité est discutable. Mais je trouve encore plus discutable que npm puisse annuler la dépublication de l'auteur.

        • [^] # Re: Quitte à partir dans tous les sens ...

          Posté par . Évalué à 9. Dernière modification le 23/03/16 à 16:41.

          Oui, cette fonctionnalité est discutable. Mais je trouve encore plus discutable que npm puisse annuler la dépublication de l'auteur.

          En quoi c'est discutable si ce logiciel est fourni sous une licence libre ? Faut prendre ça comme quelqu'un qui en publie un fork tout à fait identique. À partir du moment où le nom du module n'est pas une marque protégée il n'y a aucune raison que ça pose problème à quiconque.

  • # IPFS à la rescousse

    Posté par (page perso) . Évalué à -1.

    Personne n'apprends vraiment les lessons de ce genre de débacles.

    Le problème ce sont les humains qui viennent modifier les repos à tour de bras (y compris chez Debian), même si certains utilisateurs ne veulent pas d'updates.

    La solution est de mettre ces "repos" dans un système immutable comme IPFS:

    https://medium.com/@noffle/you-might-be-interested-in-checking-out-https-github-com-whyrusleeping-gx-75e7c90db762

  • # Commentaire supprimé

    Posté par . Évalué à 6.

    Ce commentaire a été supprimé par l'équipe de modération.

    • [^] # Re: violation de copyright, vraiment ?

      Posté par (page perso) . Évalué à 3.

      En tout cas en Europe c'est comme ça. Aux USA je ne sais pas.
      D'un autre côté le FUD suffit en général.

    • [^] # Re: violation de copyright, vraiment ?

      Posté par . Évalué à 4.

      Peut être que les avocats de kik ont décidé qu'ils devaient justifier un minimum le forfait annuel qui leur est versé. Mettre en demeure un pov'développeur indépendant, ça occuperait 1 heure de temps d'un stagiaire et permettrait de se faire mousser pour renégocier le dit forfait.
      Et qu'aux USA,

      il n'y a pas de problème

      n'est pas un problème en soit pour attaquer

    • [^] # Re: violation de copyright, vraiment ?

      Posté par (page perso) . Évalué à 6.

      Oui, je voulais parler de trademark. Kik.com a une API Rest et veut proposer un SDK en nodejs pour l'utiliser. Ils ont donc contacté l'auteur du module kik sur npm pour essayer de négocier de pouvoir récupérer le nom de ce module pour leur SDK. Derrière, ça a vite dégénéré avec des noms d'oiseaux.

      L'histoire vu du côté Kik : https://medium.com/@mproberts/a-discussion-about-the-breaking-of-the-internet-3d4d2a83aa4d

      • [^] # Re: violation de copyright, vraiment ?

        Posté par (page perso) . Évalué à -2.

        L'agressivité du mec est carrément drôle. En tout cas ça donne un autre point de vue sur l'histoire, ils (kik) ont été plutôt polis.

        • [^] # Re: violation de copyright, vraiment ?

          Posté par (page perso) . Évalué à 7.

          our trademark lawyers are going to be banging on your door and taking down your accounts and stuff like that — and we’d have no choice but to do all that because you have to enforce trademarks or you lose them.
          Can we not come to some sort of a compromise to get you to change the name without involving lawyers?

          C'est peut-être poli mais ils ont un petit peu sorti l'artillerie lourde et les menaces dès le deuxième mail alors qu'il n'avait répondu encore que : "Sorry, I’m building an open source project with that name."

        • [^] # Re: violation de copyright, vraiment ?

          Posté par . Évalué à 3.

        • [^] # Re: violation de copyright, vraiment ?

          Posté par (page perso) . Évalué à 2.

          Ils ont tout fait pour le provoquer, et puis de se plaindre qu'il est pas poli. Je déteste ce genre de fausse politesse, la demande de kik est intolérable, que ce soit fait poliment ou non.

          Ceci, pour ma part, j'aurai tout simplement ignoré les e-mails (dans le sens même pas de réponse) tant qu'il n'y a pas une avocat derrière ; on voit bien que les mecs qui gèrent npm sont de parfaits amateurs.

          • [^] # Re: violation de copyright, vraiment ?

            Posté par . Évalué à 0.

            Intolerable? Tout fait pour le provoquer?
            Le mec:
            - demande gentiment
            - ensuite, cherche un arrangement amiable, mais se fait insulter copieusement,
            - continue a cherche un areangement amiable, et se fait toujours insulter copieusement

            Je vois pas ce qu'il ya d'innacceptable la dedans.
            Il aimerait bien avoir qq chose qu'azer avait, il lui demande s'il peut l'avoir, et demande ce qu'azer voudrait en echange. Mentionner les avocats au deuxieme email etait tres maladroit, certes, mais le ton des mails reste cordial et poli.

            Quand a u fait qu'npm ait lache le nom sans meme recevoir une demande formelle d'un avocat, c'est un autre probleme.

            Autre question pour toi, si les roles etaient inverses, est ce que tu considererais la demande d'azer inacceptable?
            Certains ici trouvent inacceptable le refus de mozilla que debian utilise la marque ff (bon, plus maintenant), en quoi est ce different quand les roles sont inverses?

            Linuxfr, le portail francais du logiciel libre et du neo nazisme.

            • [^] # Re: violation de copyright, vraiment ?

              Posté par (page perso) . Évalué à 2.

              Certains ici trouvent inacceptable le refus de mozilla que debian utilise la marque ff (bon, plus maintenant), en quoi est ce different quand les roles sont inverses?

              Bah c'est pas différent. Dans les deux cas tu as le Méchant© (il est facilement reconnaissable, il a un rire sardonique, quand il apparaît à l'écran il y a de la musique symphonique dominée par les cuivres, et c'est la structure de type société) qui opprime le Gentil®™ (il est facilement reconnaissable, il sourit benoîtement, quand il apparait à l'écran il y a majoritairement des cordes, et c'est celui qui est Panurge-compliant).

            • [^] # Re: violation de copyright, vraiment ?

              Posté par (page perso) . Évalué à 2.

              La le contenu de la demande n'est pas gentille. Ce n'est pas parce que c'est poliment dit et sans insulte que c'est sympa.

              Si je demande poliment de me donner le contenu de ton portefeuille, est-ce que tu dois le faire parce que j'ai été poli ? Est-ce que je suis un mec sympa ? Est-ce que si tu m'insultes en retour, je peux l'exploiter à mon avantage ?

              En plus :

              "our trademark lawyers are going to be banging on your door and taking down your accounts and stuff like that"

              si les roles etaient inverses

              Je ne comprends pas ce que ça veut dire. L'identité des interlocuteurs n'a aucune importance.

  • # Autres exemples rigolos

    Posté par (page perso) . Évalué à 10.

    On pourrait croire que left-pad est un exemple qui sort de l'ordinaire… mais en JS, non, malheureusement.

    http://www.haneycodes.net/npm-left-pad-have-we-forgotten-how-to-program/

    There’s a package called isArray that has 880,000 downloads a day, and 18 million downloads in February of 2016. It has 72 dependent NPM packages. Here’s it’s entire 1 line of code:

    return toString.call(arr) == '[object Array]';

    There’s a package called is-positive-integer (GitHub) that is 4 lines long and as of yesterday required 3 dependencies to use. The author has since refactored it to require 0 dependencies, but I have to wonder why it wasn’t that way in the first place.
    A fresh install of the Babel package includes 41,000 files
    A blank jspm/npm-based app template now starts with 28,000+ files

    Mais comment une lib qui fait quelque chose d'aussi compliqué que vérifier qu'un objet est un entier positif ou nul peut-elle avoir 3 dépendances ? C'est simple :

    var passAll = require('101/pass-all')
    var isPositive = require('is-positive')
    var isInteger = require('is-integer')
    module.exports = passAll(isPositive, isInteger)
    • [^] # Re: Autres exemples rigolos

      Posté par . Évalué à 9.

      Je ne comprends pas pourquoi est-ce qu'un module n'a pas émergé avec un set de fonctions généralistes de ce genre ? Ça permet de tirer qu'une seul dépendance et d'avoir un set cohérent (on peut imaginer qu'elles s'utilisent plus naturellement les unes avec les autres). Bref un peu ce que fait boost en C++ ou guava en java.

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Autres exemples rigolos

        Posté par (page perso) . Évalué à 2.

        Bah le pire, c'est que ça existe ce genre de lib, comme lodash… Et c'est pourtant une lib plutôt connue.

        • [^] # Re: Autres exemples rigolos

          Posté par . Évalué à 5.

          Je n'ai pas de mal à comprendre pourquoi lodash n'a pas cette popularité. Elle vient avec une façon de penser ou d'organiser son code particulière. Peut être que JS est fonctionnel (il y en a qui disait ça dans un journal précédent), mais beaucoup de développeurs JS ne le voient pas comme ça. Leur imposer une tel organisation, ça ne passe pas.

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: Autres exemples rigolos

          Posté par . Évalué à 4.

          Est-ce que les minifiers JS savent virer du code mort ? Parce que sinon il y a une vrai raison à découper en petits modules qui vont être fusionnés par grunt, gulp ou webpack plutôt que d'utiliser un gros truc dont on utilise finalement pas grand chose.

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: Autres exemples rigolos

            Posté par (page perso) . Évalué à 3.

            Un minifieur non, heureusement.
            Un compilateur JS->JS oui. Google Closure Compiler sait le faire (et plein d'autres choses très bien). En général ça demande juste d'instrumenter un peu le code JS, en déclarant des types et autres choses du genre, mais c'est possible et très efficace. Ça fait aussi de l'inlining par exemple.

            • [^] # Re: Autres exemples rigolos

              Posté par . Évalué à 4.

              Donc il faudrait en choisir un et le module devrait venir avec en dépendance le compilateur qui va bien. C'est pas hyper pratique et de ton coté tu ne peux pas instrumenter le code des modules sans les forker ce qui demande de les renommer, de les republier, de gérer ces patchs,…

              À moins qu'il soit possible de le faire (de manière utile) sans instrumenter l'ensemble du code.

              Il me semble que c'est une particularité importe du JS pour la question des dépendances.

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Autres exemples rigolos

        Posté par (page perso) . Évalué à 5.

        Voici le point de vue d'un développeur connu pour faire beaucoup de modules avec peu de lignes de code :

        https://github.com/sindresorhus/ama/issues/10#issuecomment-117766328

        • [^] # Re: Autres exemples rigolos

          Posté par (page perso) . Évalué à 4.

          Cet article est bien intéressant, d'autant plus que contrairement à pléthore qu'on peut lire aujourd'hui, celui-ci a été écrit il y a plusieurs mois, et donc de fait loin de la polémique actuelle.

          Et d'un côté il a raison : même si le module est là pour éviter une oneliner avec 2 conditions ça reste intéressant, pas envie de se souvenir justement de comment ça s'écrit.
          Là où la question est beaucoup plus intéressante c'est pourquoi on a besoin de ces oneliners ?
          Evidemment la réponse est dans la pauvreté de la lib standard js…

          • [^] # Re: Autres exemples rigolos

            Posté par (page perso) . Évalué à 10.

            Et d'un côté il a raison : même si le module est là pour éviter une oneliner avec 2 conditions ça reste intéressant, pas envie de se souvenir justement de comment ça s'écrit.

            Je ne suis pas du tout d'accord. On se retrouve immédiatement avec des graphes de dépendances énormes et le moindre projet n'est plus du tout maintenable : quand tu as une dizaine de dépendances, tu peux te tenir au courant de leur activité, prévoir les mises-à-jour (par exemple, je sais que Django passe en 1.10 en août et j'ai déjà prévu les modifications pour être compatible), tu connais leur licence, tu peux avoir un ensemble à peu près cohérent, tu limites les doublons de code.

            Avec le JS, le moindre projet va dépendre de centaines de développeurs indépendants qui mettent leur code à jour chacun de son côté, avec des licences potentiellement exotiques, qui peuvent ajouter des bugs et affecter en cascades d'autres dépendances intermédiaires, etc.
            Comment peux-tu avoir la moindre garantie de qualité si tu ne maîtrises absolument rien au niveau des dépendances ?

            • [^] # Re: Autres exemples rigolos

              Posté par . Évalué à 2.

              Avec le JS

              C'est impossible avec pip ?

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

              • [^] # Re: Autres exemples rigolos

                Posté par (page perso) . Évalué à 10.

                Si, en t'accrochant bien, tu peux sûrement faire un projet avec des centaines de dépendances directes faites par autant de développeurs et sans aucune communauté derrière. Par contre :
                * chaque dépendance ne sera présente qu'une seule fois (impossible de charger dans le même programme plusieurs versions de la même lib).

                * ton graphe de dépendance ressemblera sûrement à une étoile et sera moins joli : tu n'auras pas à trouver que X dépend de Y qui dépend de Z qui dépend de T qui dépend de U qui dépend de V qui vient d'amener une incompatibilité.

                Théoriquement, pypi pourrait très bien être pollué de dizaines de milliers de packages de deux lignes.
                En pratique, la qualité moyenne des packages Python actuels (je ne parle pas des paquets Python 2.1 qui n'ont pas été mis à jour depuis 15 ans) est franchement pas mal. La majorité des paquets que j'utilise ont très peu de dépendances (quand ils en ont) sont publiés sur pypi, respectent tous la même norme de code (PEP008), ont une doc propre mise à jour automatiquement sur readthedocs, des tests lancés sur travis.ci, sont hébergés sur Github avec la possibilité de remonter des bugs. Encore mieux, je peux la plupart du temps créer des paquets .deb ou .rpm propres sans rien toucher.

            • [^] # Re: Autres exemples rigolos

              Posté par (page perso) . Évalué à 3.

              Je ne suis pas du tout d'accord.

              Oué mais tu interprète mal ce que je viens d'écrire. Son discours est de dire qu'il est mieux pour soit, pour son esprit, pour son développement de retenir la dépendance qui a un nom clair que le oneliner (dans le meilleur des cas) assez imbitable (dans la majorité des cas) qui va faire le même taff. Son exemple sur zéro positif/négatif est assez intéressant dans ce sens. De toute façon, s'il n'existerait pas en module npm tu ferais quoi, tu l'écrirais une première fois. Puis si tu dois l'utiliser à plusieurs endroits de ton code, tu en fais un helper, une fonction quelque part. Et comme c'est un helper tu commence à le sortir de ton métier. Puis de ton projet car en vrai tu l'utilises dans plusieurs. Et voilà pourquoi tu crées un module pour ça. C'est plutôt logique.

              Après qu'il y ait un problème avec le JS et / ou npm est une toute autre chose (et je pense que c'est le cas, mais je ne parlais justement pas de ça).

              tu peux te tenir au courant de leur activité, prévoir les mises-à-jour (par exemple, je sais que Django passe en 1.10 en août et j'ai déjà prévu les modifications pour être compatible)

              Si je ne me trompe c'est quand même l'intérêt aussi de semver. Tu as prévu ton code pour fonctionner avec telle version, tu sais que si upgrade il y a et que semver est utilisé ça ne va rien cassé (parce que tu montera que sur des mineurs par exemple). Si la montée de ton framework t'intéresse (genre django, express, etc) c'est tout autre chose, c'est un élément vraiment central. Mais dans la majorité des cas ton upgrade devrait de toute façon être motivé par une vrai raison. Tes dépendances elles ne vont pas se mettre à jour automatiquement, si tu montes en version c'est que tu le veux bien au fond.

              Comment peux-tu avoir la moindre garantie de qualité si tu ne maîtrises absolument rien au niveau des dépendances ?

              C'est pas sérieux comme argument. Sinon tu pousses le raisonnement et tu n'utilise aucune bibliothèque ou framework, aucune dépendance d'aucune sorte puisque tu ne maitrise pas la qualité de tes dépendances à moins d'aller toutes les auditer.

              • [^] # Re: Autres exemples rigolos

                Posté par (page perso) . Évalué à 0.

                Si je ne me trompe c'est quand même l'intérêt aussi de semver. .

                Non ça c'est pas semver c'est seminaire.

              • [^] # Re: Autres exemples rigolos

                Posté par (page perso) . Évalué à 4.

                C'est pas sérieux comme argument. Sinon tu pousses le raisonnement et tu n'utilise aucune bibliothèque ou framework, aucune dépendance d'aucune sorte puisque tu ne maitrise pas la qualité de tes dépendances à moins d'aller toutes les auditer.

                Tu ne peux pas pousser à fond cet argument sans le vider de sa substance. Le problème n'est d'avoir des dépendances et un graphe de dépendance quelconque. Le problème est d'avoir beaucoup de dépendances et un graphe de dépendance compliqué.
                Si tu as dix dépendances qui n'ont quasiment pas de dépendance, il est humainement possible de s'en occuper.

                Si tu as cent dépendances qui ont chacune un graphe de dépendance complexe (tu augmentes fortement la probabilité qu'il y ait un problème dans une dépendance de dépendance de dépendance, dans un code que tu ne maîtrises absolument pas), ce n'est plus humainement possible de s'en occuper.

                Ce n'est pas un problème de qualité, c'est un problème de quantité. Et en pratique, ce problème arrive avec JS, pas avec Python.

                • [^] # Re: Autres exemples rigolos

                  Posté par (page perso) . Évalué à 2.

                  A moins que tu utilises d'une manière que je ne connais pas bien, tu ne gère jamais toutes ces dépendances. Tu vas par exemple avoir une dépendance à babel qui lui utilise d'autres dépendances. Chacun s'occupant de ses dépendances. Jamais tu n'as à gérer l'ensemble de ton graph de dépendance.

                  Et en pratique, ce problème arrive avec JS, pas avec Python

                  C'est une question d'usage aussi, quand je fais du JS j'ai peu de dépendances, comme lorsque je fais du ruby.

                  • [^] # Re: Autres exemples rigolos

                    Posté par (page perso) . Évalué à 4.

                    A moins que tu utilises d'une manière que je ne connais pas bien, tu ne gère jamais toutes ces dépendances. Tu vas par exemple avoir une dépendance à babel qui lui utilise d'autres dépendances. Chacun s'occupant de ses dépendances. Jamais tu n'as à gérer l'ensemble de ton graph de dépendance.

                    Oui, c'est la théorie. Ça implique de faire confiance à toutes tes dépendances. On peut trouver du bon et du moins bon dans tous les langages ; mais encore une fois plus tu as de dépendances différentes, plus tu as de chances de retrouver avec une dépendance foireuse dont une sous-dépendance te posera problème.
                    C'est beaucoup plus facile de faire confiance à 3-4 personnes qu'à 300 ou 400. À nouveau, le problème n'est pas qualitatif mais quantitatif.

                    C'est une question d'usage aussi, quand je fais du JS j'ai peu de dépendances, comme lorsque je fais du ruby.

                    Oui, nous sommes d'accord. Tu peux faire du mauvais ou du bon code avec n'importe quel langage. En théorie, du moins. En pratique, la qualité moyenne (je ne parle pas de toi spécifiquement !) varie fortement d'un langage à l'autre.

            • [^] # Re: Autres exemples rigolos

              Posté par . Évalué à 2.

              Avec le JS, le moindre projet va dépendre de centaines de développeurs indépendants qui mettent leur code à jour chacun de son côté, avec des licences potentiellement exotiques, qui peuvent ajouter des bugs et affecter en cascades d'autres dépendances intermédiaires, etc.
              Comment peux-tu avoir la moindre garantie de qualité si tu ne maîtrises absolument rien au niveau des dépendances ?

              Logiquement tu ne t'intéresse qu'à tes dépendances direct et si tu utilise ces dépendances c'est que tu pense qu'elles sont assez malines pour faire de même. C'est l'unique façon de faire si tu ne veux pas forker tes dépendances pour jouer à mettre à jour une dépendance de ta dépendance directe.

              Il n'y a rien de complexe à savoir quelle dépendance n'est pas à jour dans tes dépendances et ce même si tu en avait plusieurs centaines de milliers. Prévoir la migration vers une version suivante qui casse ça n'arrive pas tous les jours et tu n'a pas besoin de le faire dans la seconde (pour les mises à jour de sécurité c'est différent, mais ça casse rarement).

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

              • [^] # Re: Autres exemples rigolos

                Posté par (page perso) . Évalué à 4.

                Logiquement tu ne t'intéresse qu'à tes dépendances direct et si tu utilise ces dépendances c'est que tu pense qu'elles sont assez malines pour faire de même. C'est l'unique façon de faire si tu ne veux pas forker tes dépendances pour jouer à mettre à jour une dépendance de ta dépendance directe.

                Il faut donc analyser la qualité de chaque dépendance. Ça prend du temps, surtout quand on voit les absurdités montrées plus haut (franchement, qui penserait que vérifier qu'un objet est un entier positif demande 3 dépendances ?!?). Faire ce travail pour quelques projets ne me pose pas de problème particulier, le faire pour plusieurs centaines m'en pose beaucoup plus.

          • [^] # Re: Autres exemples rigolos

            Posté par . Évalué à 5.

            Ce que tu dit est vrai dans un monde ou la gestion des dependances n'a pas de cout.
            En pratique, se taper la mise a jour d'un grand nombre de dependance, trouver ceux qui sont abandonnes, et se farcir des blagues comme celles d'hier, c'est tres loin d'etre gratuit.

            Quand c'est pour des one liners du genre return x > 0; ca devient un peu du n'importe quoi.

            Linuxfr, le portail francais du logiciel libre et du neo nazisme.

    • [^] # Re: Autres exemples rigolos

      Posté par . Évalué à 2.

      bien content de lire que tous les trucs que je n'ai jamais utilisé sont pourris, babel first. là dessus me --> []

  • # 1 fonction par module ?

    Posté par (page perso) . Évalué à 5. Dernière modification le 24/03/16 à 10:05.

    Ça choque personne que le module ne possède qu'une seule fonction ?

    Édit : bon, j'ai vu le commentaire précédent, et le lien donné qui parle de ça exactement.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.