Bonjour nal,
C'est vendredi lundi et j'avoue avoir poussé ma gueulante sur mes collègues qui ne gèrent pas leur dépendances.
Je veux dire par là : ils laissent leur gestionnaire de package tout faire pour eux en comptant sur semver qui est dans la pratique un échec (je ne retrouve plus le post que j'avais vu sur hackernews et qui expliquait au final pourquoi chrome/firefox s'en était passés et beaucoup d'autres par la suite. lien de consolation 1 et 2.)
Je suis un vieux de la vieille et je gère toujours mes dépendances à la main et par quelle magie :
1. je choisis scrupuleusement les paquets : bien codé, dépôt github vivant, documentation et pas de dépendances à d'autres paquets.
2. je met à jours ces paquets à la main : chaque nouvelle version proposée en upstream, je vérifie les commits, les issues et regarde si d'autres avant moi en ont un bon retour. Sinon je le test sur une préprod offline pour quelques-uns de mes utilisateurs.
3. je n'ajoute pas un paquet qui fait une chose tellement débile que je pourrais copier/coller ce code dans une fonction et la mettre dans un de mes helpers.
Grâce à ça on évite des usines à gaz et enculeries (terme technique de l'excellent LBDL :
- https://www.zdnet.fr/actualites/deux-modules-javascript-sabotes-par-leur-createur-39935355.htm
- https://www.clubic.com/antivirus-securite-informatique/virus-hacker-piratage/malware-logiciel-malveillant/actualite-389826-un-malware-trouve-dans-ua-parser-js-un-package-npm-tres-populaire.html
- la liste est encore longue…
Cette actu m'a fait réagir : je peux comprendre qu'un compte soit coupé en cas de malware mais dans ce cas-ci, le dév a modifié son code et s'est sabordé lui-même. Il fait ce qu'il veut avec son code !
Ce sont ceux qui l'utilisent qui n'ont qu'à vérifier leurs dépendances, personne ne les obligeait à la base à reprendre son code à l'aveugle. La communauté s'en rappellera et le sanctionnera autrement.
Pour un développeur (réponse intéressante du créateur de Putty) :
1. personne ne l'a obligé à déposer son code sous une des licences open source.
2. s'il veut être rémunéré sur son travail open source, il n'a qu'à monter sa boite de prestation ou ne pas avoir publié son code avant.
3. s'il se plaint que son soft est utilisé par x millions de développeurs et que personne ne le rémunère voir (2)
3. il a le droit de s'aborder son propre travail mais il ne doit pas s'attendre à un accueil chaleureux de ceux qui l'utilise.
4. s'il récupères du code open source par définition NO WARRANTY qui est, de mémoire, le terme absolument commun à toutes les licences open source. s'il veut se retourner contre qqun, il n'a qu'à choisir un contrat de maintenance avec une société.
Si quelque chose ne fonctionne pas ou est cassé, je ne vais pas me cacher derrière upstream ou l'accuser à ma place. Je suis responsable du foutu code que je mets en prod.
# Tu dois pas produire grand chose
Posté par Sébastien Le Ray . Évalué à 7.
Si la moitié de ce que tu racontes dans ce journal est vrai tu dois pas avoir une très grosse productivité, pas faire des choses bien compliquées ou ne jamais mettre à jour tes dépendances… (Je veux bien voir un projet moderne avec autre chose qu'un Hello World dans dépendance transitive et pour lequel tu as les compétences et le temps de tout passer en revue à chaque release)
[^] # Re: Tu dois pas produire grand chose
Posté par potate . Évalué à 7. Dernière modification le 17 janvier 2022 à 14:05.
Ça me paraît jouable sur du bas-niveau (par exemple en programmant en C ou Rust pour cibler de l'embarqué, des outils en ligne de commande).
Beaucoup moins dès qu'on se met à utiliser un framework.
L'auteur du journal peut peut-être préciser le contexte dans lequel il applique ses recommandations ?
[^] # Re: Tu dois pas produire grand chose
Posté par claudex . Évalué à 10.
Genre, il relis les commits et les issues de son compilateur à chaque mise à jour. Parce que c'est une sacré dépendance qui a un impact important sur le code final.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Tu dois pas produire grand chose
Posté par potate . Évalué à 5.
On peut pousser un peu plus loin et relire aussi le code du compilateur qui a servi à compiler le compilateur qui a servi à compiler le compilateur. :D
[^] # Re: Tu dois pas produire grand chose
Posté par barmic 🦦 . Évalué à 3.
Et un peu plus bas dans les commentaires, il explique qu'il fait même une enquête de moralité sur les dev, mais tu peux pas comprendre, t'es pas un vieux de la vielle toi
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Tu dois pas produire grand chose
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Comme le signalait potate< plus tôt, c'est une question de confiance dans les devs…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Tu dois pas produire grand chose
Posté par stopspam . Évalué à 3.
Donc j'imagine qu'entre un projet :
Toi, t'es un jeune dans le vent, YOLO tu prends le premier truc qui vient ?
[^] # Re: Tu dois pas produire grand chose
Posté par barmic 🦦 . Évalué à 5.
Je suis conscient que je ne suis pas en mesure de l'évaluer. Particulièrement parce que la plupart de mes dépendances sont composites et que juger de la probité de personne à travers leurs commits/messages dans des rapports de bug est une tâche risible (c'est biaisé, ça doit être fait dans le temps, c'est en soit discutable - qu'est-ce que tu met dans la balance -, ça n'indique rien de l'avenir,…).
Et je ne place pas une fierté dans mon comportement.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Tu dois pas produire grand chose
Posté par stopspam . Évalué à 0.
troll
[^] # Re: Tu dois pas produire grand chose
Posté par claudex . Évalué à 5.
Pas vraiment, les grosses dépendances sont au final difficiles à analyser et ce sont celles dont tu peux le moins te passer (si tu dois réimplémenter, ça te prends trop de temps). Ça ne veut pas dire qu'il faut accepter n'importe quoi, mais au final, tu ne peux faire que de l'heuristique pour valider ces technos.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Tu dois pas produire grand chose
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Moi je le fais pour chaque version de l'openjdk :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Tu dois pas produire grand chose
Posté par stopspam . Évalué à 9.
🤣
J'ai un niveau d'inspection différent en fonction de la criticité du paquet que j'utilise et de la qualité du code qu'il y a derrière.
D'où l'importance de bien choisir.
A minima :
Plus en profondeur :
Le reproche que je fais est de ne pas effectuer la vérification a minima et balancer en prod à l'aveugle
[^] # Re: Tu dois pas produire grand chose
Posté par xoddark . Évalué à 10.
Ce n'est pas le point que j'avais le plus retenu à la lecture de ton journal.
Ta pratique que tu expliques ne semble pas applicable dans plein de projet. Je pense que ça aurait été judicieux de contextualiser sur le type de projet sur lequel tu l'appliques.
[^] # Re: Tu dois pas produire grand chose
Posté par Jean Gabes (site web personnel) . Évalué à 7.
J'avoue que je suis plus de l'avis de l'auteur du journal, mais suivant la situation.
Si je me place dans mon cas, donc dans un contexte d'éditeur, il n'y a pas de différence entre ce qu'on code et ce qu'on livre comme dépendances, le seul élément qui compte c'est le livrable final, tout ce qu'il y a dedans est de notre responsabilité, d'où le fait qu'on ait une attention ultra haute sur les dépendances. Ça a un énorme coût temps/humain, mais c'est le métier d'éditeur qui veut ça.
Mais dans une situation de service peux être qu'on peux faire différemment et avoir une autre relation avec son client. On peux juste lister au client les dépendances nécessaires, et que c'est à lui qui prends cette partie à sa charge. Le prestataire pourrait le faire, mais avec un surcoût important (point de magie), ce qui fait que le client va le gérer lui, et juste mettre à jour/revert en cas de problème que lui détecte (mais c'est de la gestion interne, qui n'a pas vocation à avoir de facturation).
Est-ce que ma vision est correcte ou bien en fait c'est beaucoup moins marqué que ça?
Merci :)
[^] # Re: Tu dois pas produire grand chose
Posté par stopspam . Évalué à 10. Dernière modification le 17 janvier 2022 à 15:13.
C'est pas faux.
Une appli web de gestion avec des fonctionnalités classiques, de moyenne taille.
backend en dotnet (API) :
Une dizaine de dépendances gérés avec nuget
frontend, une SPA en full javascript SANS NODE NI NPM. :
Ça me fait 6 ou 7 paquets que je gère pour le coup à la main. Mon repo est clean.
Au total, une vingtaine de dépendances avec lesquelles je fais énormément de choses et que je suis upstream en fonction mon intérêt. Si je compare à fonctionnalités équivalentes, toujours dans le domaine du web, je vois souvent des aberrations chez d'autres développeurs avec des dizaines et dizaines de paquets pour avec des dépôts de l'ordre du Go pour une simple appli web (le syndrome NPM).
[^] # Re: Tu dois pas produire grand chose
Posté par Psychofox (Mastodon) . Évalué à 10.
Il en fait peut-être plus que pleins d'autres équipes de dev qui se pignolent dans des réunions interminables la moitié de la semaine.
[^] # Re: Tu dois pas produire grand chose
Posté par devnewton 🍺 (site web personnel) . Évalué à 10.
On peut se demande ce que doit être un projet moderne.
Faut-il vraiment que votre nouveau site de commande de pizzas livrés en trottinette soit une SPA avec Vue.js, yarn, webpack et tailwind dont le node_modules est plus lourd qu'une enclume ?
Ou alors est-ce enfin le moment de faire du
no codelow js avec seulement une fonction de 23 lignes pour aider le client a choisir la garniture ?Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Tu dois pas produire grand chose
Posté par freem . Évalué à 3.
Un truc que j'ai vécu.
Une application C++, une image debian dumpée sur des Beaglebone black. Code tout pété, pas portable (mais fait par des étudiants, donc c'est pas choquant pour moi).
Besoin de porter vers x86 + dalle graphique + dalle tactile (avant c'était RS232 vers un clavier/écran tout pourrave et tout buggué).
1ère interface graphique: ÉtronJS. Échec, trop de problèmes de stabilité, difficultés de MàJ, et les devs assassinaient leur pauvre OS qui n'avait rien demandé à coup de "wget npm | sudo bash -" ou trucs dans ce genre.
2nd interface graphique, SDL2 en xorg-less (parce qu'un certain nombre de problèmes difficiles à résoudre venaient de xorg). Échec, la gestion de l'entrée était bancale. Tentative de lecture du code (par moi, 1ère fois que j'interviens dans cette partie, du coup): nope, le code des framebuffer est… bon, disons, pas fou, et surtout, considéré expérimental.
Du coup, 3ème, faite par moi, dans l'urgence. J'ai malgré tout pris le temps de voir comment étaient foutues les (rares) libs qui prétendaient faire ce que j'avais besoin, systématiquement overkill, complexité de mise en oeuvre. Au final, ça a été faire une lib basique de widgets moi-même, en me basant sur /usr/include/linux/fb.h et une lib, qui est libinput-dev.
Si jamais il devait arriver que cette lib ne soit pas adaptée, un portage vers autre chose serait trivial.
Autre exemple, sur le même projet (l'appli graphique n'étant qu'un seul élément): le code historique implémentait, de mémoire, les websockets à la main, ou je ne sais trop comment, peut-être des fichiers dupliqués à la sauvage, je ne sais vraiment plus.
Mon choix a été d'évaluer plus d'une dizaine de libs et de lire la RFC, au cas où. Il s'avère que la plupart des libs qui font du websockets en C ou C++ ont une assez gueule, mais la RFC est trop complexe pour moi (enfin, j'y arriverai, mais perte de temps considérable). Malgré ça, j'ai trouvé une lib(pub parce qu'elle le vaut bien) qui tenait la route, mais ce n'était vraiment pas la 1ère que j'ai évaluée. J'ai également eu le plaisir de leur remonter un problème (de doc, rien de méchant) qui a été très vite corrigé. Si un jour il y avait eu un bug critique dans le code, j'aurait été probablement capable d'intervenir, de ce que j'ai lu du code (propre, documenté, par de techniques à la conW mode, du simple, de l'efficace).
Pour moi, la gestion de ses dépendances, c'est ça: un travail qui certes prend un peu de temps, mais permets de réduire les risques: de faire un mauvais choix, déjà, et si ton choix est pas optimal, soit de pouvoir corriger le problème toi-même, soit de pouvoir aisément changer pour une autre lib.
Ce n'est pas prendre l'outil parfait, vu que ça existe pas, mais de prendre un truc qui ne te fout pas dans la merde si t'as besoin de changer ou d'intervernir dessus.
Alors, non, je ne lis pas chaque foutu commit, ça serait horrible, surtout depuis que les gens s'amusent à coller les commits de CI dans l'historique du projet, mais oui, je lis quelques fichiers source "au hasard", je regarde la fréquence de commits, je lis la doc, je regarde la licence aussi.
Pour ce qui est projets à framework… bah, désolé pour ceux qui bossent avec, hein. Ce que j'ai vu, c'est que quand on se base sur un framework, il est compliqué d'en sortir le jour ou ça colle plus aux besoins. C'est sûr, il fait tout, c'est propre (vu de l'extérieur, et encore, même pas toujours) c'est rassurant, mais j'ai déjà vu des boîtes réimplémenter from scratch leur outil qu'ils avaient codé depuis plus de 10 ans parce qu'ils avaient utilisé, justement, un framework qui s'était avéré pas si adapté que ça, finalement.
Pour moi, utiliser un framework, c'est mettre tout ses oeufs dans le même panier: c'est rapide à faire, mais le jour ou le panier est percé, on perd tout.
Je comprend bien que l'auteur du journal va loin, à dire d'inspecter chaque commit, mais a bien y réfléchir, de ce que j'ai vu dans des boulots, remplacer le temps perdu à contourner l'API du framework et dans des réunions stériles pourrait très bien abattre une bonne partie du boulot en question.
Boulot qui peut être dégrossi, mutualisé, par ailleurs, par exemple en essayant d'utiliser au maximum des outils fournis par, au hasard, debian, ou toute autre distribution logicielle qui ne fait pas de rolling release. Évidemment, ça implique d'avoir confiance upstream, mais bon, on le fait déjà quand on utilise une lib de toute façon, parce que c'est pas lire un historique de commit qui va renseigner sur ce que fait vraiment le code.
Note: de manière très amusante, alors que je suis un grand utilisateur de C++, j'ai constaté qu'après revue de code, la plupart du temps, j'opte pour des bibliothèques C, dont l'interface publique tend à être plus propre, plus simple et mieux documentée. Je crois bien qu'a part GLM, je n'ai pas été impressionné par une seule lib C++ ces dernières années, en fait.
# D'un extrême à l'autre ?
Posté par xoddark . Évalué à 10.
Est-ce que parce que faire une confiance aveugle aux gestionnaires de packages est sans doute pas une bonne idée que les rejeter en block et faire à la main est la meilleure chose à faire ?
J'ai l'impression que ce que tu présentes est juste l’extrême inverse.
Gérer les dépendances d'un projet ce n'est pas trivial et demande un apprentissage (quelle que soit la méthode).
Donc le faire à la main me semble pas très accessible à des débutants, et comporte aussi ses risques. Comme ne pas mettre à jour les dépendances, y compris contre les problèmes de sécurité.
Concernant semver, dans quelle pratique c'est un échec ? Pour qui ?
Car prendre l'exemple de Firefox et Chrome qui s'en sont passé ne me semble pas très pertinent.
Déjà parce que ce sont des cas très particuliers. Ce sont des applications "finales" qui ne sont pas utilisés par d'autre programme. Ce qui est très différent des librairies qui s'incorpore dans d'autres programmes.
Ensuite si pour eux ça doit être plus simple, je ne suis pas certain que les entreprises qui surveillent les déploiements d'application soient ravies d'avoir les nouvelles fonctionnalités mêlés aux corrections de bug/failles.
[^] # Re: D'un extrême à l'autre ?
Posté par stopspam . Évalué à 6.
Je ne les rejette pas en bloc. Tout dépend de la taille de ton projet et du nombre de dépendances. S'il y a des dizaines de dépendances, ça m'interpelle sérieusement sur le projet qui est en train d'être développé. Après quand je vois 3M weekly download sur des choses comme ça, je commence à comprendre l'ampleur du problème.
C'est ce que je pensais :
Je ne retrouve plus l'article qui est passé sur hackernews il y a quelque mois. Mais cet article m'a d'autant plus fait réfléchir qu'en tant que développeur, je me suis reconnu dans l'exposé des faits et de la démonstration de la failure.
[^] # Re: D'un extrême à l'autre ?
Posté par barmic 🦦 . Évalué à 9.
Tu peux aller voir les index de CVE pour voir que oui ces dernières années log4j 1.x aussi son lot de failles. Il faut comprendre que quand on utilise des bibliothèques qui sont en fin de vie depuis 7 ans, ce n'est pas qu'il y a moins de faille, mais qu'elles ne sont pas forcément prises en compte, étudiée ni corrigée, mais ça n'empêche pas de les exploiter.
Tu parle toi-même de 3 millions de téléchargements pour une bibliothèque qui te semble inutile.
Tu fais ça comment avant d'utiliser la dite bibliothèque ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: D'un extrême à l'autre ?
Posté par Thomas Douillard . Évalué à 6.
Le problème c’est surtout qu’il n’y ait pas de fonction aussi simple que trim dans la bibliothèque standard Javascript (la quoi ?)
[^] # Re: D'un extrême à l'autre ?
Posté par Dr BG (site web personnel) . Évalué à 6.
Comme ça https://262.ecma-international.org/5.1/#sec-15.5.4.20 ? Ou j'ai loupé quelque chose (bon, y'a pas
rightetleft, mais quand même) ?[^] # Re: D'un extrême à l'autre ?
Posté par barmic 🦦 . Évalué à 6.
Ils sont dans un draft implémenté par tous les navigateurs
https://developer.mozilla.org/fr/docs/Web/JavaScript/Reference/Global_Objects/String/trimStart
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: D'un extrême à l'autre ?
Posté par Thomas Douillard . Évalué à 4.
Ah et bah manifestement j’aurai mieux fait de vérifier avant de l’ouvrir /o\
[^] # Re: D'un extrême à l'autre ?
Posté par Dring . Évalué à 7. Dernière modification le 17 janvier 2022 à 19:23.
Le fait est que NPM référence des packages qui sont des one-liners, et que ces packages sont utilisés en dépendances de truc plus gros.
Ce qui évidemment empire le "dependency hell".
Donc mauvais exemple mais vrai problème.
D'autres exemples :
https://www.zdnet.com/article/another-one-line-npm-package-breaks-the-javascript-ecosystem/
https://betterprogramming.pub/10-awesome-javascript-one-liners-utilities-for-daily-usage-ffd6a31e89d6
Non pas que ces one-liners ne soient pas utiles. C'est juste que c'est chiant de se retrouver avec "un module = une fonction = une ligne".
Et un autre point : à qui la faute ? A celui qui écrit ce truc, ou à celui qui l'utilise en dépendance au lieu de le mettre dans son propre Helper/Utils ?
[^] # Re: D'un extrême à l'autre ?
Posté par Misc (site web personnel) . Évalué à 10.
C'est sans doute par design, parce que JS est interprété et parfois téléchargé.
Prenons du code C (ou Rust, ou Go). Le compilo va éliminer le code mort, et comme il n'y a pas d'introspection à l’exécution, ce n'est pas une tache trop complexe.
C'est beaucoup plus difficile de faire ça au lancement d'un programme non compilé, vu qu'il n'y a pas stricto sensu de séparation entre compilation et exécution.
Dans le cas de python, il n'y a pas d'échange réseau, donc la pénalité d'avoir du code en trop est minime. Ça prends de l'espace disque, ça ralenti un peu le lancement, mais ça va. Et quand tu as des besoins spécifiques, tu peux revenir sur des alternatives (rust, C, etc)
Dans le cas de JS, c'est autre chose. Si tu veux du code du coté client, tu es assez vite coincé. Pour commencer, il n'y as pas trop d'alternatives pour faire du code sur le terminal client (eg, un navigateur). Il y a JS et les trucs par dessus JS. Flash et Java, c'est un peu mort depuis longtemps. Et maintenant, il y a WASM, mais c'est un changement récent. Donc il y a eu un moment ou il fallait faire avec.
À coté de ça, la solution de "je m'en fout d'avoir du code qui sert à rien" n'est pas applicable. Car non seulement ça va te coûter de l'argent (la BP est pas gratuite), mais en plus, ça va te coûter de la réactivité. Et ç'est multiplié par le nombre de clients.
Donc si tu peux pas passer sous le tapis le problème de "j'ai trop de code", et qu'un compilo ne peux pas trop t'aider (car c'est un langage de script), il y a pas trop de solutions, faut faire le taf à la main, eg avoir des libs avec 1 fonction, pour donner un contrôle fin pour les gens qui le veulent.
[^] # Re: D'un extrême à l'autre ?
Posté par barmic 🦦 . Évalué à 4.
Je suis d'accord et j'ajouterais qu'il y a des one-liners qui font le travail de rendre compatibles avec différents navigateurs qui ne sont que des passe plat avec les navigateurs récent mais font la petite glue qui va bien sinon.
Il me semble par contre qu'il y a des bibliothèques qui sont construites en modules permettant le tree shaking.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: D'un extrême à l'autre ?
Posté par Dring . Évalué à 7.
Je suis plutôt d'accord avec tes points.
Cela dit, on parle de one-liners. Qu'est-ce qui franchement empêche d'en regrouper quelques-uns dans des librairies ? On peut quand même se permettre d'embarquer 20 ou 30 ko de ça, dans la mesure où…
Mais moi, ça m'inspire aussi que fondamentalement, le développement web est tout cassé. Je comptais beaucoup sur HTML5 pour revenir à quelque chose de pérenne, mais non, les frameworks "modernes" sont toujours d'immondes bouzes qui nécessitent 2 Go d'installation avant de pouvoir écrire un "Hello, World" en noir sur fond blanc.
[^] # Re: D'un extrême à l'autre ?
Posté par freem . Évalué à 3.
C'est parce que tu prends la mauvaise fonte, avec du Comic sans MS, je suis sûr que ça serait moins compliqué, probablement pour ça que c'était tant utilisé quand les DVDs existaient pas encore.
Hop moi…
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.