←back to thread

A critique of package managers

(www.gingerbill.org)
109 points gingerBill | 5 comments | | HN request time: 0.736s | source
Show context
spacebanana7 ◴[] No.45167772[source]
> "This is the automation of dependency hell. The problem is that not everything needs to be automated, especially hell. Dependency hell is a real thing which anyone who has worked on a large project has experienced. Projects having thousands, if not tens of thousands, of dependencies where you don’t know if they work properly, where are the bugs, you don’t how anything is being handled—it’s awful.

This the wrong thing to automate. You can do this manually, however it doesn’t stop you getting into hell, rather just slow you down, as you can put yourself into hell (in fact everyone puts themselves into hell voluntarily). The point is it makes you think how you get there, so if you have to download manually, you will start thinking “maybe I don’t want this” or “maybe I can do this instead”. And when you need to update packages, being manual forces you to be very careful."

I sympathise with this, but I have to respond that we have to live within existing ecosystems. Getting rid of npm and doing things manually won't make building SPAs have fewer dependencies, build would be incredibly slow and painful.

replies(5): >>45167807 #>>45167944 #>>45167982 #>>45168021 #>>45169142 #
pmarreck ◴[] No.45167807[source]
There already is a (partial) solution to dependency hell: Nix.

It will at least massively help prevent things from breaking unexpectedly.

It won't prevent you from having to cascade a necessary upgrade (such as a security fix) across the entire project until resolution/new equilibrium is achieved.

My solution to the latter is simply to try to depend on as few things as possible. But eventually, the cancer will overtake the project if it keeps growing.

Source: Have worked on a million-LOC Ruby app

replies(1): >>45169182 #
1. gingerBill ◴[] No.45169182[source]
Nix isn't a solution to the problem of package managers. It just a better way to package management system, which thus makes it easier to go to dependency hell. So I'd argue it puts fuel on the flames.

The solution is just to depend on less and manage them manually.

replies(2): >>45170553 #>>45176030 #
2. greener_grass ◴[] No.45170553[source]
If we depend on less then we are capping what we can build to only what we can write and manually integrate. This is dis-empowering.
replies(2): >>45170674 #>>45187589 #
3. gingerBill ◴[] No.45170674[source]
I'd argue quite the opposite. You can build a lot more than you think, you just need to be encouraged.
4. pmarreck ◴[] No.45176030[source]
I don't think that is a solution. In fact I don't think there are any "solutions". I do think there are tradeoffs though.
5. gnatmud8 ◴[] No.45187589[source]
if you depend on more, you are capping what you can build to only what you can manage to get working and integrate, plus you also lose control over the code; for me personally, it's a lot easier to write a complicated algorithm, than it is to figure out a complex build system for a random library in the wild (with few exceptions like miniaudio); and it's especially worth it, because when i understand the problem, i can usually define a way better api for my usecase than any library writer can