Live data from Hacker News

A critique of package managers

gingerbill.org

151–160 of 220 posts

Re: A critique of package managers

#151

Earlier quoted context omitted.

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

From what I've seen. The Odin has three package collections: `base`, `core` and `vendor`.

`base` is intrinsically necessary to port Odin. `core` seems to be its standard library, your `libc`, `xml`, etc.

And `vendor` is everything else. So you basically get the Python's '`core` is where packages go to die' approach iff they take backwards compatibility seriously. Otherwise, they have breaking changes mid-language version change.

EDIT: Package collections not packages per gingerBill.

Re: A critique of package managers

#152

Earlier quoted context omitted.

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

It doesn't necessarily "manage" the packages. It just sees them in your project and compiles them. You manage them yourself.

Re: A critique of package managers

#153

Earlier quoted context omitted.

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

It doesn't necessarily "manage" the packages. It just sees them in your project and compiles them. You manage them yourself.

If that's what happens, I think in the following claim:

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

...the word "automatically" should be dropped. Of course compilers compile any supplied dependency "automatically", but it is so obvious that we don't often use the adverb just for that.

Re: A critique of package managers

#154
post #151

Earlier quoted context omitted.

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

From what I've seen. The Odin has three package collections: `base`, `core` and `vendor`. `base` is intrinsically necessary to port Odin. `core` seems to be its standard library, your `libc`, `xml`, etc. And `vendor` is everything else. So you basically get the Python's '`core` is where packages go to die' approach iff they take backwards compatibility seriously. Otherwise, they have breaking changes mid-language ver…

So they are trying the Linux distribution model of packages, right? (Compare `vendor` with, say, Ubuntu's `universe`.)

Re: A critique of package managers

#155
post #131

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.

Yes, but that's quite different from how language package managers are used. A typical C/C++ project doesn't tell you to build it via apt/rpm instead you are expected to provide the dependencies using whatever means you choose or they are included in the repo. This means you don't need to fight a package manager to get fully offline or reproducible builds for example.

RPM and APT packages are also usually not maintained by the upstream developer but by distro developers who care about making different packages work together so you don't get the dependency hell problem as a user.

Re: A critique of package managers

#156
post #151

Earlier quoted context omitted.

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

From what I've seen. The Odin has three package collections: `base`, `core` and `vendor`. `base` is intrinsically necessary to port Odin. `core` seems to be its standard library, your `libc`, `xml`, etc. And `vendor` is everything else. So you basically get the Python's '`core` is where packages go to die' approach iff they take backwards compatibility seriously. Otherwise, they have breaking changes mid-language ver…

Those are library/package collections which contain multiple different packages, not the packages themselves.

And we will take backwards compatibility seriously when we hit 1.0, and only "break" on major versions.

Re: A critique of package managers

#157

Earlier quoted context omitted.

> The term “evil” is being used partially hyperbolic to make a point. Kind of bonkers this even needs to be said, and even then it's missed/ignored.

The title is provocative and attention grabbing. -- It's completely fair game to react to the provocation rather than the substance of the article itself. (Or, rather, it's silly to use attention grabbing rhetoric, then complain that people paid attention to the rhetoric). I'd prefer instead a more balanced title like "Remember to Consider the Costs When Using Package Managers", or whatever.

> It's completely fair game to react to the provocation rather than the substance of the article itself.

Yeah, but its down right stupid to do so.

The title isn't even misleading or part of a Motte-and-bailey argument.

People just hear "Package Managers are Evil" and assume that the author means you shouldn't use third party dependencies. Which is NOT what's being argued.

But I guess you'd know that, if you read passed the title.

Re: A critique of package managers

#158
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…

> Did Yocto ever clean up how they manage the sysroot?

It's better than before but you still need to sandbox manually if you want good reproducibility.

Honestly, for reproducibility alone. There is better than Yocto nowadays. It is hard to beat Nix at this game. Even Bazel based build flows are somewhat better.

But in the embedded world, Yocto is pretty widespread and almost the de-facto norm for Linux embedded.

Re: A critique of package managers

#159
post #151

Earlier quoted context omitted.

From what I've seen. The Odin has three package collections: `base`, `core` and `vendor`. `base` is intrinsically necessary to port Odin. `core` seems to be its standard library, your `libc`, `xml`, etc. And `vendor` is everything else. So you basically get the Python's '`core` is where packages go to die' approach iff they take backwards compatibility seriously. Otherwise, they have breaking changes mid-language ver…

Those are library/package collections which contain multiple different packages, not the packages themselves. And we will take backwards compatibility seriously when we hit 1.0, and only "break" on major versions.

> And we will take backwards compatibility seriously when we hit 1.0, and only "break" on major versions.

I'm talking about post 1.0 language choices:

- Choose backwards compatibility. Packages frozen in time, you get "Packages go to std to die." - Choose to break backwards compatibility. The ecosystem is split, some choose to go Odin 2 some are Odin 3.

Re: A critique of package managers

#160
post #157

Earlier quoted context omitted.

The title is provocative and attention grabbing. -- It's completely fair game to react to the provocation rather than the substance of the article itself. (Or, rather, it's silly to use attention grabbing rhetoric, then complain that people paid attention to the rhetoric). I'd prefer instead a more balanced title like "Remember to Consider the Costs When Using Package Managers", or whatever.

> It's completely fair game to react to the provocation rather than the substance of the article itself. Yeah, but its down right stupid to do so. The title isn't even misleading or part of a Motte-and-bailey argument. People just hear "Package Managers are Evil" and assume that the author means you shouldn't use third party dependencies. Which is NOT what's being argued. But I guess you'd know that, if you read pass…

Sorry but I lack any respect for authors that use clickbaits. Call them put and move on seem the best approach.
Post reply on HN