3 ms·

> Or is there something I'm missing here? There may be some platform-specific dependencies, but at least when building on Windows, I saw 67 dependencies downlo

> Or is there something I'm missing here? There may be some platform-specific dependencies, but at least when building on Windows, I saw 67 dependencies downloaded. One thing that may be skewing the count is that internally coreutils is packaged with one crate per command. There are about 100 commands, so you'll have seen at least that many separate crates building. They're listed here: https://github.com/uutils/coreutils/blob/6e8c901204934029c883553bf8c69b9c43577714/Cargo.toml#L217 https://github.com/uutils/coreutils/blob/6e8c901204934029c88... My impression is that ecosystems where tracking dependencies is hard tend to discourage them, while ecosystems where tracking dependencies is easy encourage them. The coreutils crate depends on separate md5, sha1, sha2, and sha3 crates, if managing external dependencies was hard I imagine those would be bundled together. But it is easy, so it makes sense to organise the crates so that each just provides one specific piece of functionality. Think single responsibility principle applied to packaging.

gmueckl 6y ago
Urgh, that's just a verification nightmare waiting to happen. Who is going to wade through all that mess, review every package, pin its version etc...? You need reproducability before you can get safety and security.
- AgentME 6y ago
  Cargo uses lockfiles by default to pin all dependencies of an application, so reproducibility shouldn't be much of an issue.
  - hedora 6y ago
    No one reads lockfiles. In python, people have successfully backdoored projects by sending a PR that upgrades a dependency and regenerates the lockfiles. Somewhere in the 1MB lockfile patch, they pin a dependency to a version with a known remotely exploitable flaw (sometimes a zero day, sometimes not).
hedora 6y ago
If you care about security, api stability and legal compliance, you should minimize the number of developers and packages you trust. My rule of thumb is that, for a team of ~10 developers, each package dependency adds a week or two of developer maintenance time each year or so. Having a dozen packages where one will do, and having them do the same thing recursively means you need to spend 144 times longer dealing with such things.
- james-mcelwain 6y ago
  Why is number of packages and not package size the relevant metric here? Especially when all the packages live in the same repository, there's practically no more overhead to review each package qua package, versus just a bunch of directories in a package monolith. This "144 times longer" number seems pulled completely out of thin air.
  - eximius 6y ago
    Both are relevant. To their point, each additional maintainer is also a hidden dependency of each package, so the number of packages is relevant.
    - afiori 6y ago
      In the case in question the dependency count as crates is separate from the dependency count as git repos. In this case things that would normally be one big library where split in many different functional crates in the same repo.
  - hedora 6y ago
    Twelve packages with twelve dependencies each is 144. I’ve seen >10x this level of blow up on multiple products at multiple companies. One company missed installing malware behind all the firewalls of most of the fortune 500 by less than a week. We made a procedural change to the build process of a product that had been shipping for years. The change hit our CI/CD 5 days before one of the big language package managers started spewing malware at us. Package maintainer count bloat is a serious real world problem. Ignoring it is negligent.

gmueckl 6y ago

Urgh, that's just a verification nightmare waiting to happen. Who is going to wade through all that mess, review every package, pin its version etc...? You need reproducability before you can get safety and security.

AgentME 6y ago
Cargo uses lockfiles by default to pin all dependencies of an application, so reproducibility shouldn't be much of an issue.
- hedora 6y ago
  No one reads lockfiles. In python, people have successfully backdoored projects by sending a PR that upgrades a dependency and regenerates the lockfiles. Somewhere in the 1MB lockfile patch, they pin a dependency to a version with a known remotely exploitable flaw (sometimes a zero day, sometimes not).

hedora 6y ago

If you care about security, api stability and legal compliance, you should minimize the number of developers and packages you trust. My rule of thumb is that, for a team of ~10 developers, each package dependency adds a week or two of developer maintenance time each year or so. Having a dozen packages where one will do, and having them do the same thing recursively means you need to spend 144 times longer dealing with such things.

james-mcelwain 6y ago
Why is number of packages and not package size the relevant metric here? Especially when all the packages live in the same repository, there's practically no more overhead to review each package qua package, versus just a bunch of directories in a package monolith. This "144 times longer" number seems pulled completely out of thin air.
- eximius 6y ago
  Both are relevant. To their point, each additional maintainer is also a hidden dependency of each package, so the number of packages is relevant.
  - afiori 6y ago
    In the case in question the dependency count as crates is separate from the dependency count as git repos. In this case things that would normally be one big library where split in many different functional crates in the same repo.
- hedora 6y ago
  Twelve packages with twelve dependencies each is 144. I’ve seen >10x this level of blow up on multiple products at multiple companies. One company missed installing malware behind all the firewalls of most of the fortune 500 by less than a week. We made a procedural change to the build process of a product that had been shipping for years. The change hit our CI/CD 5 days before one of the big language package managers started spewing malware at us. Package maintainer count bloat is a serious real world problem. Ignoring it is negligent.