Hacker News Reader

Comment by jiggawatts | Hacker News Reader

To the people that like to make the argument that it’s the developers’ individual responsibility to regularly check their dependencies and transient dependencies…

… explain to me how many hours per month you dedicate to this task yourself. Now go look at this list. This isn’t even “code”, it’s a utility.

Tell me again how “this is fine”.

Large standard libraries exist for a reason, and this is it: so that we can have one dependency instead of thousands. So that reviewing non-standard dependencies is tractable. So that upgrades don’t break because of NP-complex rules violations even computers can’t resolve let alone humans.

View on HN

This isn’t a great article, tbh. Most of the complexity is from compiling the Rust compiler (and its “large standard library”) from source. Of course that’s going to be a complicated affair, because a production-quality compiler is not a simple bit of code. Normally this would just be a binary package, but it looks like MacPorts didn’t have said package for the author’s platform at the time.

Second, the upgrade didn’t fail at all. The author has misinterpreted the log. This is understandable given the wording (“Unable to uninstall…Uninstall forced”), but all it’s saying is that it is forcibly uninstalling a package that’s being depended on, because the depending package is also being upgraded. The upgrade process completes fully, despite taking a very long time.

I would agree with you had I (the author) intentionally wanted to install Rust, but I didn’t. This was a Python dependency randomly bringing all of Rust along with it and that is insane no matter how you slice it.

My real-world example of this is that the ASP.NET Session State module for SQL Server pulls in basically half of the Azure client libraries… in case you’re using Azure SQL with Azure Entra identity authentication.

Don’t use those things? Tough! Your 500 kB web app now has 500 MB of dependencies shovelled into it whether you like it or not.

But this was only necessary because the binary packages for py310-cryptography did not exist on MacPorts for your platform at the time you did the upgrade. MacPorts therefore had to build from source, and that necessitates installing the compiler. Nowadays, with the appropriate binary package on macports.org, installing the Rust compiler should no longer be necessary. For example, I have successfully installed the py310-cryptography module just now off of MacPorts without rust being installed. Rust binary packages intentionally do not rely on a language runtime (only libc), whereas Rust source packages will naturally need to rely on the Rust compiler.

Building from source is always going to be more painful than installing a binary package; I have packages in MacPorts that can take hours to build from source (binaries not available, usually due to using an uncommon mix of feature flags). It's misleading to suggest, however, that the little package you installed carries 393 dependencies, when those are the dependencies of the compiler rather than the package itself.

I think we agree that MacPorts is doing the best it can here.

In my view[1], the issue is a package in one language introducing a dependency on an entirely different, uncommon, language runtime and toolchain. Until relatively recently (at least with respect to the post), the cryptography package did not require Rust at all. A secondary issue is the amount of dependencies actually involved in building a cryptography package. How many of those dependencies are compiler dependencies or not is not relevant to my mind; the cryptography package still transitively depends on them by way of the compiler (and by way of the package manager) and any one of those dependencies could probably read my SSH keys or do $deity knows what else to my computer.

[1]: I agree this isn't particularly well expressed by the post, nor perhaps by these comments here, but now I have to run get a haircut!

Reply on news.ycombinator.com