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

201–210 of 220 posts

Re: A critique of package managers

#201

Post by [deleted] »

1GZ0 wrote: post #169
rgoulter wrote: post #162

Earlier quoted context omitted.

In the article, the author does say "I am not advocating to write things from scratch", while also describing third party dependencies as liabilities (e.g. security vulnerabilities), that people are too trusting of third party dependencies, that people overestimate the quality of third party dependencies. I think you're splitting hairs if you're saying that these points from the article argue against package managers…

Liability: "Something for which one is liable; an obligation, responsibility, or debt." Third party dependencies absolutely are liabilities. You are liable to vet them, inspect their licenses and keep them updated while ensuring that they continue working with your existing code. This is not something package managers help you do. Package managers like NPM make it trivial to skip these steps entirely. What is being a…

[deleted]

Re: A critique of package managers

#202

Post by lifthrasiir »

dismalaf wrote: post #176
lifthrasiir wrote: post #171

Earlier quoted context omitted.

We call that a build system. It is not like that there is no build system; you have an integrated build system that is optimized for typical situations. Which is great by its own, but other languages and toolings would have optimized other metrics (for example, you can't ignore Cargo when talking about Rust's build system) so it is not a fair comparison.

I mean, is a "build system" even real? Or does it just exist because of a shortcoming with a compiler? All "compilers" have multiple steps usually invoking other programs at some point: parsing, actual code transformation, linking, etc..., some also find packages, some rely on an external tool or long command line invocations. But yes, Odin builds it into their compiler. Rust doesn't but does have Cargo. Both are eas…

> All "compilers" have multiple steps usually invoking other programs at some point: parsing, actual code transformation, linking, etc..., some also find packages, some rely on an external tool or long command line invocations.

There is no technical reason the compiler can do the job of build system, but they are typically separated because of separation of concerns. Rustc needs not be tightly coupled with Cargo---it just has to understand enough of package concepts (`--extern`) for the actual compilation, so they can be independently managed and evolve. Odin's would be the polar oppsite, while Zig's approach is somewhere in the middle (compiler-as-a-library).

Re: A critique of package managers

#203

Post by BobbyTables2 »

1718627440 wrote: post #150
BobbyTables2 wrote: post #144

Earlier quoted context omitted.

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.

One certainly can, but such is not default.

Things using autotools evolved to be “manual user friendly” in the sense that application features are automatically enabled based on auto detected libraries.

But for automated builds, all those smarts get in the way when the build environment is subject to variation.

In theory, the Yocto recipe will fully specify the application configuration regardless of how the environment varies…

Of course, in theory the most Byzantine build process will always function correctly too!

Re: A critique of package managers

#204

Post by SideburnsOfDoom »

ozim wrote: post #197
SideburnsOfDoom wrote: post #185

Earlier quoted context omitted.

> That's not package manager problem that's registry problem I do not think that the two are cleanly separable. They are client and server ends of the same system. And I think my point is that I view it as more of a server (registry) and governance problem than the OP author does. Despite the fact that my employer also has an internal package feed, the security of nuget.org and the central public feed is intrinsic to…

Article is discussing „package manager” as generic concept. My argument was that this concept is not the problem. Problem is in governance of NPM while NuGet or Maven are stricter and therefore it is registry governance problem. But on the other hand NPM is much more popular than any other registry.

> Article is discussing „package manager” as generic concept. My argument was that this concept is not the problem. Problem is in governance of NPM

Then we're in agreement that the article's author has the wrong end of the stick, by focusing on the client end of the file transfer connection.

Re: A critique of package managers

#205

Post by gingerBill »

ModernMech wrote: post #188
gingerBill wrote: post #186

Earlier quoted context omitted.

What do you consider your set of "Batteries Include"?

Basically the stuff in here: https://www.ros.org

I've been looking through the repository list and that is not "batteries included", that's "everything, the kitchen sink, and the city".

Unless I am reading this (https://index.ros.org/?search_repos=true) wrong.

Re: A critique of package managers

#206

Post by gingerBill »

ModernMech wrote: post #183
1GZ0 wrote: post #170

Earlier quoted context omitted.

Its not clickbait though. You should try reading the article before passing judgement. Its not like the article is called "5 facts that will make you hate package managers. Number 5 will shock you"

It was clickbait because the article, which I did read, did not support the contention that package managers are evil . Therefore "evil" seems to be used in a hyperbolic way to grab attention, which makes it clickbait, specifically ragebait.

I wouldn't class it as clickbait myself, but I will stand by the use of the word "evil". I am using evil in the very old fashioned sense: the privation of the good. Is the title provocative? Yes. But that's the point of the article in general. I am trying to argue that they are a net bad with virtually no good upsides to them for the programming world as a whole. They've automated something at scale which should not have been automated. And to be clear, there is no solution to the problems they are trying to solve, rather it's all about trade-offs.

I a little annoyed that HackerNews post renamed it to "A critique of package managers" because that implies very different connotations. I'd view an article written like that as if I have some criticisms that could be addressed, rather than the entire concept being bad from the start.

Re: A critique of package managers

#207

Post by gingerBill »

SideburnsOfDoom wrote: post #204
ozim wrote: post #197

Earlier quoted context omitted.

Article is discussing „package manager” as generic concept. My argument was that this concept is not the problem. Problem is in governance of NPM while NuGet or Maven are stricter and therefore it is registry governance problem. But on the other hand NPM is much more popular than any other registry.

> Article is discussing „package manager” as generic concept. My argument was that this concept is not the problem. Problem is in governance of NPM Then we're in agreement that the article's author has the wrong end of the stick, by focusing on the client end of the file transfer connection.

Huh? I am not saying the repositories have (or should have) no responsibility, but you are also responsible for your own actions.

The popularity of such repositories and package managers are due to users of them.

And the concepts are trivially separable in my opinion. A package manager uses a repo of packages to download from. You don't need a package manager to use a repo. And a package manager could be just local to your machine and thus not need an external repo either. I know in practice the two are combined but that doesn't mean they are not distinct concepts.

Re: A critique of package managers

#208

Post by Ygg2 »

gingerBill wrote: post #164
Ygg2 wrote: post #159

Earlier quoted context omitted.

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

I already know all that, that's why we are being very conservative and slow when it comes to figuring out what is meant to be in 1.0.

I don't think it will matter. There will be things people want that Odin won't have in the vendor package list.

Then those people will have to manage dependencies, which is a hell on its own. Which will cause problems. Because people are super lazy so they will automate it. In the end only thing no package manager gets you is multiple package managers to juggle.

Many languages started without package managers and eventually got them - Java, JavaScript, Python, C, C++

Re: A critique of package managers

#209

Post by gingerBill »

Ygg2 wrote: post #208
gingerBill wrote: post #164

Earlier quoted context omitted.

I already know all that, that's why we are being very conservative and slow when it comes to figuring out what is meant to be in 1.0.

I don't think it will matter. There will be things people want that Odin won't have in the vendor package list. Then those people will have to manage dependencies, which is a hell on its own. Which will cause problems. Because people are super lazy so they will automate it. In the end only thing no package manager gets you is multiple package managers to juggle. Many languages started without package managers and eve…

Again, I am not against third party packages, and manual management of dependencies just slows down your progression to hell. There is no "solution" to this problem, only trade-offs.

I know people are lazy and will automate hell. That's the entire point of the article: not everything that can be automated ought to be automated.

And the argument about multiple package managers to juggle is only the case IFF there are multiple competing ones, which with Odin, I honestly doubt it would happen if we enforced what a package is in the language. I just don't want to officially endorse one ever because I do view them to be evil.

And I don't care many languages started without them, I am not going to give in.

Re: A critique of package managers

#210

Post by ModernMech »

gingerBill wrote: post #205
ModernMech wrote: post #188

Earlier quoted context omitted.

Basically the stuff in here: https://www.ros.org

I've been looking through the repository list and that is not "batteries included", that's "everything, the kitchen sink, and the city". Unless I am reading this ( https://index.ros.org/?search_repos=true ) wrong.

That's pretty much my point -- my batteries aren't your batteries. If you're building houses, kitchen sinks are your parts. I'm high up on the abstraction stack so I need SLAM, and Kalman filters, advanced logging, mesh pub/sub networking in my stdlib. Here's another example of one of my "batteries" that is perhaps a little more concise: https://www.mathworks.com/products/image-processing.html

Something like OpenCV in the language stdlib is my idea of "batteries included". Like I said: what you consider batteries are not what people in my line of work consider batteries; Odin advertises "batteries included" but looking through the list I wouldn't use any of that in my day to day.

That's why Rust has a small stdlib of just the essentials, because doing so keeps things general, and everyone gets to choose their own idea of batteries.

Post reply on HN