Hacker News Reader

Comment by DougBTX | Hacker News Reader

> 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/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.

View on HN

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.

Cargo uses lockfiles by default to pin all dependencies of an application, so reproducibility shouldn't be much of an issue.

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).

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.

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.

Both are relevant. To their point, each additional maintainer is also a hidden dependency of each package, so the number of packages is relevant.

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.

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.

I'm not suggesting that we should stop reviewing dependencies. I'm pushing back against the idea that internally structuring a large repo or project via independent modules necessarily explodes the burden to review.

It may be the case that this preference for well modularized code leads to lots of disparate small packages in the ecosystem, but within the scope of a single project, I see no reason why modularization poses any intrinsic risk.

Reply on news.ycombinator.com