4 ms·
it's completely stupid to measure "number of dependencies" in absolute numbers. Lots of packages have a `-macros` or `-derive` transient dependency, meaning a
by orf 2y ago
it's completely stupid to measure "number of dependencies" in absolute numbers.
Lots of packages have a `-macros` or `-derive` transient dependency, meaning a single dependency can end up coutning as 3 additional dependencies.
Rust makes it simple to split packages into workspaces - for example, regex[1] consists of `regex-automata` and `regex-syntax` packages.
This composition and separation of concerns is a sign of good design, and not an npm-esque hellhole.
1. https://crates.io/crates/regex/1.11.1/dependencies https://crates.io/crates/regex/1.11.1/dependencies
- rectang 2y agoI suppose you could say that the audit burden scales linearly with the number of module publishers, with a small additional amount on every release point to confirm that the publisher is still who they purport to be and hasn't been compromised. This is assuming that the audit consists of validating dependency authorship, and not the more labor-intensive approach of reviewing dependency code.
- 0x457 2y agoHard no. Burden scales with number of lines. Lines being split into smaller chunks (crates) only speed up the process in long run.
- orf 2y agoHard yes, burden scales with number of authors and not number of lines. That’s… the whole rationale about not liking lots of small packages.
- rcxdude 2y agoThat depends on whether you want to vet the authors or the code itself.
- orf 2y agoSure, but then we could just take all the dependency code and put it in single line to make it quicker to review.
- 0x457 2y agoAre you reviewing code you're pulling into your code base (that is usually organized and counted in lines, smartass) or authors? Either way, with rust it's a handful of authors, but just because they are proven to be good faith actors, doesn't mean trust in their code is implied when we're talking about supply chain hardening.
- rectang 2y agoFrom upthread: > This is assuming that the audit consists of validating dependency authorship, and not the more labor-intensive approach of reviewing dependency code. So, obviously: authors. I took your reply of "hard no" to be a rejection of validating authors as sufficient hardening and an assertion that only line-by-line code review meets your standards. Fine, but if your answer is always going to be "doesn't matter, not good enough", we can't have a reasonable conversation about how best to validate authors.
- 0x457 2y agoNo, line-by-line meets my standard. I don't think just validating authorship is enough.
- arccy 2y agothat's kind of on rust for pushing crates front and center rather than groupings of crates that are developed / reviewed / released together as a single cohesive unit (typically a git repo). e.g. go dependencies are counted on modules (roughly git repos), rather than packages (directories, compilation units). java is counted in packages rather than classes.
- adamc 2y agoThe vulnerability to supply chain attacks gives me pause. It's not unique to rust and it bothers me with npm or Python as well.
- rcxdude 2y agoIndeed. It's actually been quite handy on a few occasions to be able to just pull in a smaller crate as opposed to the whole project. (in constrast to, say, boost in C++, which is a big mess of a dependency even though it's one that goes to at least a little bit of effort to let you split it up, but through an ad-hoc process as opposed to a standard package management system). (I would genuinely be interesting in an experiment which pushes this as far as possible: what if each function was a 'package'? There's already a decent understanding of how dependencies within a library work in the compiler, what if that extended to the package manager? You would know exactly what code you actually needed, and would only pull in exactly what was necessary)