3 ms·

The article raises some interesting points but I still disagree that comparing the mess of JavaScript dependencies[0] to GNU utils is warranted - the level of t

The article raises some interesting points but I still disagree that comparing the mess of JavaScript dependencies[0] to GNU utils is warranted - the level of trust is fundamentally different. I have some reasonable intuition that the authors of GNU packages as well as the distro maintainers do a good job writing, packaging and vetting these tools. That's not really the case with left-pad or is-array. I can trust that an update to cat or ls will not break my system because enough people have looked at it, but I really don't know what's gonna happen when I update left-pad (without even knowing it, because a it's a transitive dependency). The other point is that GNU utils are self-contained binaries and don't usually include transitive dependencies 20 levels deep. Even when the problems these packages solve are not 100% trivial, unless you trust that library to be continuously maintained, maybe consider not adding the dependency, instead taking inspiration from the code and writing your own, maybe even simplified version of it (careful with that, you don't want to write your own crypto, for example - but when we're talking about a three-file "compare XML files" test util that hasn't been updated since 2014, just copying that code into your project might be the better approach). [0]: And it really is JavaScript - I don't know of any other language with the same kind of explosion of micro-packages. I'm not saying that other languages never experience dependency hell - of course they do - only that it's usually not as horrifying as it is with JS.

amyjess 4y ago
> I can trust that an update to cat or ls will not break my system because enough people have looked at it, but I really don't know what's gonna happen when I update left-pad (without even knowing it, because a it's a transitive dependency). The biggest difference here is that distros vet their maintainers, often with a lengthy process similar to hiring someone at a company, while NPM and similar repos are entirely self-serve, where anyone can register an account and just publish whatever packages.
- iudqnolq 4y ago
  > The biggest difference here is that distros vet their maintainers, often with a lengthy process similar to hiring someone at a company This is very surprising to me. During the debacle over Rust in the Python cryptography package maintainers were saying it's unreasonable to expect them to read dependency changelogs.
  - bombolo 4y ago
    Well they went to use rust and broke their package for thousands of users. They do not provide precompiled files for everyone and suddenly gcc isn't enough to build. Debian (and I guess ubuntu) are stuck on a year old version because of using rust before packaging rust stuff has been solved. They aren't the most careful of maintainers, it seems. https://lwn.net/Articles/845535/ https://lwn.net/Articles/845535/
    - iudqnolq 4y ago
      Even if you think the cryptography devs did something wrong, doesn't it prove the distro maintainers weren't doing any review? If they didn't catch something called out in the changelog I don't see how anyone can claim they're catching things you'd need to carefully read the source to find. (I'm not blaming distro maintainers, it would be impossible for them to do actual reviews.)
      - bombolo 4y ago
        Uh? Distro maintainers knew… but there was nothing to be done about it… It was end users of the package that didn't know, had a dependency like "<=X" and with the big change in a minor version got the rust version they could not compile (and thus run).
        iudqnolq 4y ago
        Nope, if you check out the original threads it's full of distro maintainers complaining they were surprised. To clarify, these are maintainers of software that depends on cryptography, not maintainers of cryptography. Those maintainers weren't reviewing dependencies on an ongoing basis.
    - jborean93 4y ago
      They did and still do provide precompiled wheels for cryptography. The problem was the version of pip distributed by some of the major Linux distributions was too old to understand the newer tags that would have told them to use the wheels. Because of this I agree that they probably jumped the gun on making the switch but if you had a new enough pip you don’t need to compile it. On the plus side it gave the impetus for Python to define wheels for musl and other arch’s which is a nice outcome.
- dTal 4y ago
  >distros vet their maintainers The AUR wants a word :)
  - majormajor 4y ago
    I tried Arch for a while, and having to go use AUR stuff for things that were a lot easier or built-in in Ubuntu or Fedora while not being vetted at the same level was one of the big things that caused me to go back to those others. If I wanted to do my own work I'd go back to Gentoo. ;)
yyyk 4y ago
>The other point is that GNU utils are self-contained binaries and don't usually include transitive dependencies 20 levels deep. Mostly because UNIX programs don't actually call other programs all that much. Composability happens on the shell level, but not so much in the program code level. e.g. The implementation of 'cat -n' isn't 'cat | pr -n' or the equivalent C, and pr usually isn't in a separate package from cat.

amyjess 4y ago

> I can trust that an update to cat or ls will not break my system because enough people have looked at it, but I really don't know what's gonna happen when I update left-pad (without even knowing it, because a it's a transitive dependency). The biggest difference here is that distros vet their maintainers, often with a lengthy process similar to hiring someone at a company, while NPM and similar repos are entirely self-serve, where anyone can register an account and just publish whatever packages.

iudqnolq 4y ago
> The biggest difference here is that distros vet their maintainers, often with a lengthy process similar to hiring someone at a company This is very surprising to me. During the debacle over Rust in the Python cryptography package maintainers were saying it's unreasonable to expect them to read dependency changelogs.
- bombolo 4y ago
  Well they went to use rust and broke their package for thousands of users. They do not provide precompiled files for everyone and suddenly gcc isn't enough to build. Debian (and I guess ubuntu) are stuck on a year old version because of using rust before packaging rust stuff has been solved. They aren't the most careful of maintainers, it seems. https://lwn.net/Articles/845535/ https://lwn.net/Articles/845535/
  - iudqnolq 4y ago
    Even if you think the cryptography devs did something wrong, doesn't it prove the distro maintainers weren't doing any review? If they didn't catch something called out in the changelog I don't see how anyone can claim they're catching things you'd need to carefully read the source to find. (I'm not blaming distro maintainers, it would be impossible for them to do actual reviews.)
    - bombolo 4y ago
      Uh? Distro maintainers knew… but there was nothing to be done about it… It was end users of the package that didn't know, had a dependency like "<=X" and with the big change in a minor version got the rust version they could not compile (and thus run).
      - iudqnolq 4y ago
        Nope, if you check out the original threads it's full of distro maintainers complaining they were surprised. To clarify, these are maintainers of software that depends on cryptography, not maintainers of cryptography. Those maintainers weren't reviewing dependencies on an ongoing basis.
  - jborean93 4y ago
    They did and still do provide precompiled wheels for cryptography. The problem was the version of pip distributed by some of the major Linux distributions was too old to understand the newer tags that would have told them to use the wheels. Because of this I agree that they probably jumped the gun on making the switch but if you had a new enough pip you don’t need to compile it. On the plus side it gave the impetus for Python to define wheels for musl and other arch’s which is a nice outcome.
dTal 4y ago
>distros vet their maintainers The AUR wants a word :)
- majormajor 4y ago
  I tried Arch for a while, and having to go use AUR stuff for things that were a lot easier or built-in in Ubuntu or Fedora while not being vetted at the same level was one of the big things that caused me to go back to those others. If I wanted to do my own work I'd go back to Gentoo. ;)

yyyk 4y ago

>The other point is that GNU utils are self-contained binaries and don't usually include transitive dependencies 20 levels deep. Mostly because UNIX programs don't actually call other programs all that much. Composability happens on the shell level, but not so much in the program code level. e.g. The implementation of 'cat -n' isn't 'cat | pr -n' or the equivalent C, and pr usually isn't in a separate package from cat.