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

▲

gingerBill 4 days ago | parent [-]

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.

▲

greener_grass 4 days ago | parent | next [-]

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.

	▲	gingerBill 4 days ago \| parent \| next [-]
		I'd argue quite the opposite. You can build a lot more than you think, you just need to be encouraged.
	▲	gnatmud8 3 days ago \| parent \| prev [-]
		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

▲

pmarreck 4 days ago | parent | prev [-]

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.