Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A critique of package managers

gingerbill.org

Post reply on HN
Print view View original

51–60 of 220 posts

Re: A critique of package managers

#51

Post by alexvitkov »

adev_ wrote: post #47
zahlman wrote: post #43

Earlier quoted context omitted.

I mostly agree, but > Some of us works in environment where the final product is an agglomerate of >100 of components developed by >20 teams around the world. Versioned over ~50 git repositories. Often mixed with some proprietary libraries provided by third-party providers. Gluing, assembling and testing all of that is far beyond the "LOL, just stick to the SDL" mindset proposed here. Does this somehow prevent you fr…

> Does this somehow prevent you from vendoring everything? Yes. Because in these environment soon or later you will be shipping libraries and not executable . Shipping libraries means that your software will need to be integrated in other stacks where you do not control the full dependency tree nor the versions there. Vendoring dependencies in this situation is the guarantee that you will make the life of your custom…

You're making your customer's life miserable by having dependencies. You're a library, your customer is using you to solve a specific problem. Write the code to solve that and be done with it.

In the game development sphere, there's plenty of giant middleware packages for audio playback, physics engines, renderers, and other problems that are 1000x more complex and more useful than any given npm package, and yet I somehow don't have to "manage a dependency tree" and "resolve peer dependency conflicts" when using them.

Re: A critique of package managers

#52

Post by hliyan »

I don't know what the solution to this problem is, but I do remember a time (around 20 years ago) when this wasn't a big problem. Was working on a fairly large (each module between 50k - 100k LOC) C++ system. The process for using libraries:

1) Have problem that feels too complicated to hand-code.

2) Go on Internet/forums, find a library. The library is usually a small, flat collection of atomic functions.

3) A senior engineer vets the library and approves it for use.

4) Download the stable version: header file, and the lib file for our platform (on rare occasions, build it from source)

5) Place the .h file in the header path, and the lib file in the lib path; update the Makefile.

6) #include the header and call functions.

7) Update deployment scripts (bash script) to scp the lib file to target environment, or in some cases, use static linking.

8) Subscribe to a mailing list and very occasionally receive news of a breaking change that requires a rebuild.

This may sound like a lot of work, but somehow, it was a lot less stressful than dealing with NPM and node_modules today.

Re: A critique of package managers

#53

Post by gingerBill »

alphazard wrote: post #40

There's a fair bit of semantic quibbling here. Regardless of how they define these terms, producing a list of hashes which function as a commitment to specific versions of dependencies is a technique essential to modern software development. Whatever the tools are called, and whatever they do, they need to spit out a list of hashes that can be checked into version control. You could just use git submodules, but in pr…

The semantic quibbling is just to explain what a package manager isn't.

Also, use git subtrees, not git submodules. What people think submodules are, are actually subtrees and most people don't know about them.

As for "good" package managers, they are still bad because of what I said in the article.

Re: A critique of package managers

#54

Post by karmakaze »

The post goes on to say that random packages are not necessarily better than what members of your team could make. At the end it gets to:

> Through manual dependency management. Regardless of the language, it is a very good idea that you know what you are depending on in your project. Copying and vendoring each package manually, and fixing the specific versions down is the most practical approach to keeping a code-base stable, reliable, and maintainable. Automated systems such as generic package managers hide the complexity and complications in a project which are much better not hidden away.

So that makes all of us human package managers. It's also true that you can get a package manager from internet folk that works better than the processes and utilities your team cobbles together to ease the burden.

Re: A critique of package managers

#55

Post by drzaiusx11 »

kunley wrote: post #31
Ygg2 wrote: post #16

Earlier quoted context omitted.

I've seen plenty of intelligent people acting pretty stupid. As my psychology professor used to say. "Smart is how efficiently use your intelligence. Or don't." So someone pretty low IQ can be smart - Forrest Gump. Or someone high IQ can be dumb occasionally - a professor so very attuned to his research topic at expense of everything else.

How is this relating to the alleged inexperience of the original author? Not sure what do you mean.

The above comment is merely pointing out that a 10y+ experienced language designer can still have naive viewpoints on application development. Anyone who's built a non-trivial userspace application knows that realistically you'll have to reach outside a particular languages standard library in most cases to provide value without reinventing wheels.

In other words: when someone's knowledge is disproportionately localized/siloed to their prospective subfield or domain of expertise, it does not necessitate generalization to others.

I'm certainly not saying this is the case with this particular individual, as I'm personally not familiar with their background. I'm simply stating that it's a plausible explanation for when experts in one domain make naive assertions about another domain they might not have the same experience in.

Re: A critique of package managers

#56

Post by adev_ »

alexvitkov wrote: post #51
adev_ wrote: post #47

Earlier quoted context omitted.

> Does this somehow prevent you from vendoring everything? Yes. Because in these environment soon or later you will be shipping libraries and not executable . Shipping libraries means that your software will need to be integrated in other stacks where you do not control the full dependency tree nor the versions there. Vendoring dependencies in this situation is the guarantee that you will make the life of your custom…

You're making your customer's life miserable by having dependencies. You're a library, your customer is using you to solve a specific problem. Write the code to solve that and be done with it. In the game development sphere, there's plenty of giant middleware packages for audio playback, physics engines, renderers, and other problems that are 1000x more complex and more useful than any given npm package, and yet I so…

> You're making your customer's life miserable by having dependencies. You're a library, your customer is using you to solve a specific problem. Write the code to solve that and be done with it.

And you just don't know what you are talking about.

If I am providing (lets say) a library that provides some high level features for a car ADAS system on top of a CAN network with a proprietary library as driver and interface.

This is not up to me to fix or choose the library and the driver version that the customer will use. He will choose the certified version he will ship, he will test my software on it and integrate it.

Vendoring dependency for anything which is not a final product (product as executable) is plain stupid.

It is a guarantee of pain and ABI madness for anybody having to deal with the integration of your blob later on.

If you want to vendor, do vendor, but stick to executables with well-defined IPC systems.

Re: A critique of package managers

#57

Post by gingerBill »

torginus wrote: post #29

This reads much more like a critique of traditional open-source development than package managers themselves. The author asserts that most open-source projects don't hit the quality standards so that their libraries can be just included, and they'll do what they say. I assert that this is because there's no serious product effort behind most libraries (as in no dedicated QA/test/release cycle), no large commercial pr…

This critique applies to even closed-source development that uses open-source code bases.

I have an article on my unstructured thoughts on the problems of OSS/FOSS which goes into more depth about this: https://www.gingerbill.org/article/2025/04/22/unstructured-t...

Re: A critique of package managers

#58

Post by gingerBill »

karmakaze wrote: post #54

The post goes on to say that random packages are not necessarily better than what members of your team could make. At the end it gets to: > Through manual dependency management. Regardless of the language, it is a very good idea that you know what you are depending on in your project. Copying and vendoring each package manually, and fixing the specific versions down is the most practical approach to keeping a code-ba…

Yes. That's the entire point, but it should not be automated which is my point.

Re: A critique of package managers

#59

Post by gingerBill »

epage wrote: post #8

> Dependency hell [0] 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. [0] https://en.wikipedia.org/wiki/Dependency_hell I find it strange that they use a term with a common meaning, link to that meaning,…

Where?

Re: A critique of package managers

#60

Post by gingerBill »

adev_ wrote: post #41

The argument here is (in brief) "Package management is hell, package managers are evil. So let's handle the hell manually to feel the pain better". And honestly speaking: It is plain stupid. We can all agree that abusing package management with ~10000 of micro packages everywhere like npm/python/ruby does is completely unproductive and brings its own considerable maintenance burden and complexity. But ignoring the de…

I am not sure how you got this conclusion from the article.

> So let's handle the hell manually to feel the pain better

This is far from my position. Literally the entire point is to make it clearer you are heading to dependency hell, rather than feel the pain better whilst you are there.

I am not against dependencies but you should know the costs of them and the alternatives. Package managers hide the complexity, costs, trade-offs, and alternative approaches, thus making it easier to slip into dependency hell.

Post reply on HN