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

141–150 of 220 posts

Re: A critique of package managers

#141

Post by forrestthewoods »

bigstrat2003 wrote: post #129
jitl wrote: post #49

Earlier quoted context omitted.

Rust’s big issue here is the anemic standard library. I think overall the strategy makes some amount of sense; since there’s so much crazy alchemy like depending on nightly, no_std, etc in Rust, including stuff in std has more downside in Rust than in a language that’s more stable like Go. But it’s annoying to have to deal with 3 different time libraries and 3 different error creation libraries and 2 regex libraries…

The very sparse std is one of the few genuine mistakes I think Rust has made. I know the arguments for it, but I don't find them persuasive. A batteries included standard library, in my view, is just plain better and every modern language should have one.

Oh man I feel the opposite. Rust is an example where a sparse stdlib is clearly superior and better and more successful.

I mostly write C++ whose committee is incompetent and sniffs glue. And I deal a lot with Khronos committed who design pure garbage. “Design by Committee” is a pejorative for a reason.

Re: A critique of package managers

#142

Post by acoustics »

gingerBill wrote: post #57
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...

This is why I'm so glad that I work in a closed monorepo now. There is no package management, only build tooling.

I find myself nodding along to many of the technical and organizational arguments. But I get lost in the licensing discussion.

If it is a cultural problem that people insist on giving things away for free (and receiving them for free), then viral licenses can be very helpful, not fundamentally pernicious.

Outside of the megaprojects, my mental model for GPL is similar to proprietary enterprise software with free individual licenses. The developer gets the benefits of open projects: eyeballs, contributors, adoption, reputational/professional benefits, doing a good deed (if that motivates them) while avoiding permissively giving everything away. The idea that it's problematic that you can't build a business model on their software is akin to the "forced charity" mindset—"why did you make something that I can't use for free?"

If you see a GPL'd bit of code that you really want to use in your business, email the developers with an offer of $X,000 for a perpetual commercial license and a $Y,000/yr support contract. Most are not so ideologically pure to refuse. It's a win-win-win: your business gets the software, the developers don't feel exploited, noncommercial downstream users can enjoy the fruits of open software, and everybody's contributed to a healthier attitude on open source.

Re: A critique of package managers

#143

Post by BobbyTables2 »

forrestthewoods wrote: post #138
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.

These aren’t always separate.

Some distos might try to support multiple versions of a library. That could require installing it to different prefixes instead of the default. Thus, the build system will have to comprehend that.

Re: A critique of package managers

#144

Post by BobbyTables2 »

adev_ wrote: post #73
seba_dos1 wrote: post #68

Earlier quoted context omitted.

You keep confirming that you don't know what you are talking about. The vendoring step happens at something like Yocto or equivalent and that's what ends up being certified, not random library repos.

Yes exactly. And in addition: Yocto (or equivalent) will also be the one providing you the traceability required to guarantee that what you ship is currently what you certified and not some random garbage compiled in a laptop user directory.

Did Yocto ever clean up how they manage the sysroot?

It used to have a really bad design flaw. Example: - building package X explicitly depends on A to be in the sysroot - building package Y explicitly depends on B in the sysroot, but implicitly will use A if present (thanks autoconf!)

In such a situation, building X before Y will result in Y effectively using A&B — perhaps enabling unintended features. Building Y then X would produce a different Y.

Coupled with the parallel build environment, it’s a recipe for highly non deterministic binaries — without even considering reproducibility.

Re: A critique of package managers

#145

Post by drzaiusx11 »

drzaiusx11 wrote: post #137
kunley wrote: post #78

Earlier quoted context omitted.

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

Put another way: what makes this time different? How does this designer's proclivity and push towards X learn from our collective past mistakes; what does it bring to the table?

Yes dependency hell is "bad", but we have several language and package management systems today from ninja to uv that make various, obvious trade offs. Optimizing developer time, ergonomics, reproducible builds, configuration complexity are just some of the axes these pre-existing systems focus on.

If you're extremely lucky you get to pick a system that aligns with your style of work and ideals for how software should be built. If you're not, and like the rest of us, you get stuck with everyone else's poor decisions and are forced to make do. All code is legacy code given the right time horizon, so think about software with all those manual dependencies included on disk and nowhere else. How do you safely apply those required security fixes, etc. Don't be user hostile, this will just lead to our past sins like the C of old.

From a purist perspective, you can forgo all other software that you have not written in-house / or does not come with the standard library. This is the monk approach, but outside a few niche work environments that's untenable.

Re: A critique of package managers

#146

Post by lifthrasiir »

dismalaf wrote: post #133
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.

Isn't that a (built-in) package manager if it works for general packages? Or does it work only for selected dependencies?

Re: A critique of package managers

#147

Post by 1718627440 »

skydhash wrote: post #134
Macha wrote: post #131

Earlier quoted context omitted.

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.

Most distros have their own package manager including source packages and an automated way to go from there to binaries. So the build scripts you mention are part of the package manager.

Re: A critique of package managers

#148

Post by 1718627440 »

saulpw wrote: post #132
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…

In C and C++ you don't need the transitive dependencies for compilation, you only need the header of the direct dependencies. As for linking they are only needed when linking dynamically, which was much less prevalent 20 years ago.

Re: A critique of package managers

#149

Post by forrestthewoods »

BobbyTables2 wrote: post #143
forrestthewoods wrote: post #138

Earlier quoted context omitted.

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

These aren’t always separate. Some distos might try to support multiple versions of a library. That could require installing it to different prefixes instead of the default. Thus, the build system will have to comprehend that.

Not everything in the world revolves around Linux. Distros terrible choices around shared library architecture has nothing to do with build systems for most languages.

Re: A critique of package managers

#150

Post by 1718627440 »

BobbyTables2 wrote: post #144
adev_ wrote: post #73

Earlier quoted context omitted.

Yes exactly. And in addition: Yocto (or equivalent) will also be the one providing you the traceability required to guarantee that what you ship is currently what you certified and not some random garbage compiled in a laptop user directory.

Did Yocto ever clean up how they manage the sysroot? It used to have a really bad design flaw. Example: - building package X explicitly depends on A to be in the sysroot - building package Y explicitly depends on B in the sysroot, but implicitly will use A if present (thanks autoconf!) In such a situation, building X before Y will result in Y effectively using A&B — perhaps enabling unintended features. Building Y th…

> but implicitly will use A if present (thanks autoconf!)

When you want reproducibility, you need to specify what you want, not let the computer guess. Why can't you use Y/configure --without-A ? In the extreme case you can also version config.status.

Post reply on HN