Ben déjà parce que npm ne compile pas vraiment et que c'est compliqué de savoir ce que l'on garde ou pas, contrairement à un langage compilé qui sait tout ce qui est référencé.
Oui, c'est bien ce que je voulais souligner :
langage interprété : beaucoup de dépendances == problématique
langage compilé : beaucoup de dépendances == osef
cela vient aussi en doublon du gestionnaire de paquets de ta distrib.
Sauf que sous Linux, tu n'as pas 2 distributions qui fournissent les mêmes versions de la lib dont tu dépend. Ce qui rend la tâche difficile pour celui qui veut distribuer son logiciel. Plusieurs choix s'offrent à lui :
supporter toutes les distros et chacune des versions de la lib via du code spécifique, des tests de régressions, etc...
supporter une seule version de la lib et donc ne supporter potentiellement que peu de distro Linux
se reposer sur des environnements type flatpak ou docker qui standardise entre plusieurs distro les libs incluses
Je te laisse deviner quel choix est le plus souvent fait.
Heureusement qu'on n'a pas attendu Rust pour faire de la compilation statique...
Vas-y, montre mois les binaires fait en C/C++ qui compilent statiquement boost, Gtk, Qt, et autres giga-lib, alors qu'ils n'utilisent que 3 fonctions de ces dernières.
[^] # Re: Cargo.lock affligeant
Posté par David Delassus (site web personnel) . En réponse au lien Rewriting the GNU Coreutils in Rust. Évalué à 0.
Oui, c'est bien ce que je voulais souligner :
Sauf que sous Linux, tu n'as pas 2 distributions qui fournissent les mêmes versions de la lib dont tu dépend. Ce qui rend la tâche difficile pour celui qui veut distribuer son logiciel. Plusieurs choix s'offrent à lui :
Je te laisse deviner quel choix est le plus souvent fait.
Vas-y, montre mois les binaires fait en C/C++ qui compilent statiquement boost, Gtk, Qt, et autres giga-lib, alors qu'ils n'utilisent que 3 fonctions de ces dernières.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg