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

131–140 of 220 posts

Re: A critique of package managers

#131

Post by Macha »

account42 wrote: post #66
NoboruWataya wrote: post #32

I see this a lot with Rust where I will depend on one or two external crates for a simple application and then I am shocked to see dozens of dependencies being pulled in when I go to build. I actually think Cargo's support for feature gates and conditional compilation could in theory be a strong mitigation against this as crates can avoid pulling in dependencies unless you actually need a feature that relies on them,…

> If Rust didn't have Cargo to automate dependency hell, someone would create a third party script to fill the gap. Possibly but not guaranteed. Some other languages without a built in package manager haven't had an external one manage to take over the ecosystem, most (in)famously C and C++, while others have.

The package manager for C/C++ is apt, or rpm, or whatever package manager your system uses. These package managers were designed for the world of C/C++ software so it's less surprising that these languages haven't found as much of a push towards language package managers.

Re: A critique of package managers

#132

Post by saulpw »

hliyan wrote: post #52

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 senio…

I think the main thing that makes this workable is "The library is usually a small, flat collection of atomic functions."

I find that it's the hell of transitive dependencies--you as a developer can reasonably vet a single layer of 10-30 standalone libraries. But if those libraries depend on other libraries, etc, then it balloons into hundreds or thousands of dependencies, and then you're sunk.

For what it's worth, I don't think much of this is essential complexity. Often a library is complicated because it supports 10 different ways of using it, but when you use the library, you're only using 1 of those ways. If everyone is only using 10% of thousands of transitive dependencies, the overall effect is incredibly complicated, but could have been achieved with 10-100% more short-term effort. Sure, "it took twice as long to develop but at least we don't have 10x the dependencies" is a hard sell to management (and often to ourselves), but that's because we usually choose to ignore the costs of depending on software we don't understand and don't control. We think that we're cleverly avoiding having to maintain and secure those libraries we outsourced, but most open-source developers aren't doing a great job of that anyway.

Often it really is easier to develop something from scratch, rather than learn and integrate a library. Not always though, of course.

Re: A critique of package managers

#133

Post by dismalaf »

izzylan wrote: post #119

I don't see the value in making it even harder to build software. I want to make things. Downloading a dependency manually and then cursing at the compiler because "it's right there! why won't it load!!" is just gonna make me want to build software less. Anyone I want to work with on a project is going to have to have the same frustration and want to work on the project less. Only even more because you see they downl…

> Downloading a dependency manually and then cursing at the compiler because "it's right there! why won't it load!!"

Odin's compiler knows what a package is and will compile it into your program automatically.

Re: A critique of package managers

#134

Post by skydhash »

Macha wrote: post #131
account42 wrote: post #66

Earlier quoted context omitted.

> If Rust didn't have Cargo to automate dependency hell, someone would create a third party script to fill the gap. Possibly but not guaranteed. Some other languages without a built in package manager haven't had an external one manage to take over the ecosystem, most (in)famously C and C++, while others have.

The package manager for C/C++ is apt, or rpm, or whatever package manager your system uses. These package managers were designed for the world of C/C++ software so it's less surprising that these languages haven't found as much of a push towards language package managers.

It is not. Most distro have their own build scripts that target the specific library name that is needed. Dependencies is mostly done through a mix of convention, helper programs/scripts and compiler args.

Re: A critique of package managers

#135

Post by chillfox »

travisgriggs wrote: post #127

As I age, I do everything I can to avoid "one more dependency". There's a perverse nerd bragging effect that takes place where people equate their value as a programmer to how many dependencies they can name drop and mash up into their solution. It makes sense, since we evaluate each other, and the more dependencies you can reference in your workpast, the more stepping stones you've stepped on and therefor, been long…

I definitely used to look for reasons to include cool new dependencies that I found, just to try and do something with cool libraries.

But as I got bit by the various issues with dependencies multiple times over the years, I have ended up preferring as few as possible and ideally zero beyond the standard library for hobby projects if I can get away with it.

Re: A critique of package managers

#136

Post by pmarreck »

gingerBill wrote: post #72
pmarreck wrote: post #3

Earlier quoted context omitted.

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 overta…

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.

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.

Re: A critique of package managers

#137

Post by drzaiusx11 »

kunley wrote: post #78
drzaiusx11 wrote: post #55

Earlier quoted context omitted.

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 locali…

I don't buy it. A guy designing and then implementing a programming language has a much bigger chance to put a lot of rational thinking into the tooling like dependency manager, than a typical language consumer, who can and often is easily falling into the languages emo wars.

As the original article points out, not all languages come out of the box with a sane/rationally designed dependency manager. I can think of only a handful in that category. The vast majority of languages fall short and rely on secondary community projects to prop up the dependency management for the language: maven, gradle, npm, pip/pypi, now uv, etc.

Language designers in general terms will fall into the "more knowledgeable than the average developer"category , but let's not pretend they're anything but mere mortals like the rest of us.

NGL Ive somehow lost the thread and can't tell if we're talking about language integrated dependency managers in the abstract (in the OP), or specifically speaking about golang, odin or something else. I don't know what the emo wars are specifically in reference to but I think we jumped the shark here.

Re: A critique of package managers

#138

Post by forrestthewoods »

izzylan wrote: post #119

I don't see the value in making it even harder to build software. I want to make things. Downloading a dependency manually and then cursing at the compiler because "it's right there! why won't it load!!" is just gonna make me want to build software less. Anyone I want to work with on a project is going to have to have the same frustration and want to work on the project less. Only even more because you see they downl…

This is an argument for a good build system, not a package manager.

Re: A critique of package managers

#139

Post by flysand7 »

This article, although is trying to provide some arguments as for why package managers are "evil", I found the argumentation pretty weak/non-descriptive. It's good if you have the experiences that confirm a specific point of view, but I think these experiences need to be explained in some more detail, because people reading your article may have similar experiences and therefore would find it hard to agree with your points - just like me.

To give a concrete example, you said that javascript does not have a definition of a "package" in its langauge. But what does that really mean, and why should it lead to package manager managers? Because for me, a person who has worked with javascript just a little bit, I know package.json exists and most of the package managers I've worked with agree on what the contents of this file mean. If we limit our understanding to just npm, yarn and probably bun, we don't see how that causes or contributes to the dependency hell problem (sure it exists, but how?).

You said that Go mitigates the issue of dependency hell to some degree, but this is an interesting thought, give it more exploration! Why should something like Go not have this problem not be not as severe as in Javascript?

I may not remember the details of what you said in the article and I would like to check, but currently I can't access the site because it times-out for me.

Re: A critique of package managers

#140

Post by drzaiusx11 »

This article is a bit all over the map with discussions of high trust societies and their relation to language design and software dependency management.

That said I think the final takeaway is that systems that allow you to pin versions, vendor all those dependencies and resolve/reproduce the same file tree regardless of who's machine it's on (let's assume matching architectures for simplicity here) is the goal.

Note that removing 'manually' here, this still works:

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

The article's emphasis on the manual aspect of management of dependencies is a bit of loss, as I don't particularly believe it _has to be manual_ in the sense of manually copying files from their origin into your file tree; that certainly is a real world option, but few (myself included) would take that monk-like path again. I left this exact situation in C land and would not consider going back unless adopting something like ninja.

What the OP is actually describing is a "good" package manager feature set and many (sadly not most/all) do support this exact feature set today

PS I did chuckle when they defined evil in terms of something that gets you to dependency hell faster. However, we shouldn't be advocating for committing the same sins of our fathers.

Post reply on HN