4 ms·

I typically vet dependencies by doing reverse lookups, e.g.: https://crates.io/crates/slab/reverse_dependencies https://crates.io/crates/slab/reverse_dependenc

I typically vet dependencies by doing reverse lookups, e.g.: https://crates.io/crates/slab/reverse_dependencies https://crates.io/crates/slab/reverse_dependencies And then looking into the biggest results and understanding community sentiment. Ultimately you need to trust the authors. Do this enough and you start seeing the same popular projects, making it easier to trust things. > sometimes I just want my code to be simple and tight and understandable from beginning to end I hear ya! This is one reason I wrote my own async runtime, and the output of “cargo build” fits on my screen. :) But I don’t recommend this unless you have a LOT of time.

lijogdfljk 5y ago
Yea, i don't really get the distrust of the ecosystem tbh. Yea, i agree the `0.x` stuff is annoying/concerning, but the volume of dependencies feels very.. meh. I use NixOS for example. The number of things i download is _insane_ when i build my system. This isn't a Rust or JavaScript "problem", it's just how natural distribution of work occurs. People build off of the work of their peers. And if you reduce the friction of work distribution, like how NPM and Crates do, you naturally get a lot - sometimes to a comical degree. However are we going to expect crate authors to repeatedly reinvent wheels? Would we trust them if they did?
- user-the-name 5y ago
  I would say that this is why reducing friction this way is not actually a good thing. It has disastrous effects on the entire ecosystem when including a dependency is too easy. It means people will not question whether they should be including a dependency, because it is so easy to do.
  - lijogdfljk 5y ago
    I don't think the issue is "too easy" here, but the lack of downstream verification tools. If you had a clear metric for all the parts that go into a library you wouldn't worry about how many there were. And if the library author likewise cared about their libraries metric, they wouldn't arbitrarily choose low-quality libraries. Friction isn't useful here imo. Trust is just as bad with high friction, just maybe less moving pieces. Not having verified metrics seem to me the real problem. Some sort of safety rating that bubbles up from all the dependencies. Changes to software owners would also have to cause issues in this system too.
- nonameiguess 5y ago
  This doesn't ring true to me. I get that you need to have some dependencies. But if you go build Linux From Scratch, you get a total of 68 packages, most of which are part of the GNU project and come from common authors. That gets you an entire operating system. On the other hand, when I was writing a book using mdbook and wanted a plugin that does token replacement, it pulled in 238 dependencies. To do token replacement. Up that to the scale of an entire operating system written in Rust, and now what are you looking at? At least thousands. Supply chain auditing eventually becomes impossible if you have a separate vendor per function. Put another way, if you go and build Firefox from source, the number of Rust crates and NPM modules it pulls in automatically during its own build is more than the total number of packages in Linux From Scratch and Beyond Linux From Scratch combined. Not every library needs to be the size of glibc, but Rust and Node have gone too far in the opposite direction. I don't know what you have in your Nix build, but even Linux From Scratch is already bloated because it includes a bunch of build and test tools you don't need to just run an OS. The Arch base system is 27 packages.
  - halpert 5y ago
    Is an operating system really a fair comparison? Most libraries depend on the operating system, and the usage of OS independent libraries would be limited to mostly operating systems. Not a very big market.
  - lmm 5y ago
    > But if you go build Linux From Scratch, you get a total of 68 packages, most of which are part of the GNU project and come from common authors. That gets you an entire operating system. Sure, because dependency management for C is a joke^H^H extremely cumbersome and so you get coarse-grained packages that bundle lots of functionality and are a pain to upgrade. Why is number of dependencies something you care about? Bundling 10 functions together and calling them a library doesn't make them any easier to audit than auditing them individually, all it does is bloat programs that only needed one of them. Getting supply chain attestation to scale is a legitimate problem, but a solvable one - e.g. we could have organisations that would vouch for a large range of authors or packages.
michael_j_ward 5y ago
It would be nice to subscribe to any change in that dependency relationship. If `proxy-auditor-crate` upgrades, then probably I should to. And probably more importantly, if `proxy-auditor-crate` drops a dependency because they no longer trust it, then I definitely want to be notified.

lijogdfljk 5y ago

Yea, i don't really get the distrust of the ecosystem tbh. Yea, i agree the `0.x` stuff is annoying/concerning, but the volume of dependencies feels very.. meh. I use NixOS for example. The number of things i download is _insane_ when i build my system. This isn't a Rust or JavaScript "problem", it's just how natural distribution of work occurs. People build off of the work of their peers. And if you reduce the friction of work distribution, like how NPM and Crates do, you naturally get a lot - sometimes to a comical degree. However are we going to expect crate authors to repeatedly reinvent wheels? Would we trust them if they did?

user-the-name 5y ago
I would say that this is why reducing friction this way is not actually a good thing. It has disastrous effects on the entire ecosystem when including a dependency is too easy. It means people will not question whether they should be including a dependency, because it is so easy to do.
- lijogdfljk 5y ago
  I don't think the issue is "too easy" here, but the lack of downstream verification tools. If you had a clear metric for all the parts that go into a library you wouldn't worry about how many there were. And if the library author likewise cared about their libraries metric, they wouldn't arbitrarily choose low-quality libraries. Friction isn't useful here imo. Trust is just as bad with high friction, just maybe less moving pieces. Not having verified metrics seem to me the real problem. Some sort of safety rating that bubbles up from all the dependencies. Changes to software owners would also have to cause issues in this system too.
nonameiguess 5y ago
This doesn't ring true to me. I get that you need to have some dependencies. But if you go build Linux From Scratch, you get a total of 68 packages, most of which are part of the GNU project and come from common authors. That gets you an entire operating system. On the other hand, when I was writing a book using mdbook and wanted a plugin that does token replacement, it pulled in 238 dependencies. To do token replacement. Up that to the scale of an entire operating system written in Rust, and now what are you looking at? At least thousands. Supply chain auditing eventually becomes impossible if you have a separate vendor per function. Put another way, if you go and build Firefox from source, the number of Rust crates and NPM modules it pulls in automatically during its own build is more than the total number of packages in Linux From Scratch and Beyond Linux From Scratch combined. Not every library needs to be the size of glibc, but Rust and Node have gone too far in the opposite direction. I don't know what you have in your Nix build, but even Linux From Scratch is already bloated because it includes a bunch of build and test tools you don't need to just run an OS. The Arch base system is 27 packages.
- halpert 5y ago
  Is an operating system really a fair comparison? Most libraries depend on the operating system, and the usage of OS independent libraries would be limited to mostly operating systems. Not a very big market.
- lmm 5y ago
  > But if you go build Linux From Scratch, you get a total of 68 packages, most of which are part of the GNU project and come from common authors. That gets you an entire operating system. Sure, because dependency management for C is a joke^H^H extremely cumbersome and so you get coarse-grained packages that bundle lots of functionality and are a pain to upgrade. Why is number of dependencies something you care about? Bundling 10 functions together and calling them a library doesn't make them any easier to audit than auditing them individually, all it does is bloat programs that only needed one of them. Getting supply chain attestation to scale is a legitimate problem, but a solvable one - e.g. we could have organisations that would vouch for a large range of authors or packages.

michael_j_ward 5y ago

It would be nice to subscribe to any change in that dependency relationship. If `proxy-auditor-crate` upgrades, then probably I should to. And probably more importantly, if `proxy-auditor-crate` drops a dependency because they no longer trust it, then I definitely want to be notified.