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

61–70 of 220 posts

Re: A critique of package managers

#61

Post by zahlman »

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…

When you're a library, your customer is another developer. By vendoring needlessly, you potentially cause unavoidable bloat in someone else's product. If you interoperate with standard interfaces, your downstream should be able to choose what's on the other end of that interface.

Re: A critique of package managers

#62

Post by gingerBill »

Octoth0rpe wrote: post #4

> Each dependency is a potential liability. I mean, sure. So what does the solution look like? From my perspective it looks like a tool that is able to update your dependencies so that you can easily pick up bug fixes in your dependencies, which sounds an awful lot like a package manager. > JavaScript is great example of this as there are multiple different package managers for the language (npm being one of the most…

> So what does the solution look like?

There are no solutions, only trade-offs. And the point is that not everything needs to be, nor ought to be, automated. And package managers are a good point of this.

And yes, a language with an ill-defined concept of a package in the language itself is a problem of the language, but the package managers are not making it any better.

Re: A critique of package managers

#63

Post by alexvitkov »

adev_ wrote: post #56
alexvitkov wrote: post #51

Earlier quoted context omitted.

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

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

If you're writing an ADAS system, and you have a "dependency tree" that needs to be "resolved" by a package manager, you should be fired immediately.

Any software that has lives riding on it, if it has dependencies, must be certified against a specific version of them, that should 100% of the time, without exceptions, must be vendored with the software.

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

The exact opposite. Vendoring is the ONLY way to prevent the ABI madness of "v1.3.1 of libfoo exports libfoo_a but not libfoo_b, and v1.3.2 exports libfoo_b but not libfoo_c, and in 1.3.2 libfoo_b takes in a pointer to a struct that has a different layout."

If you MUST have libfoo (which you don't), you link your version of libfoo into your blob and you never expose any libfoo symbols in your library's blob.

Re: A critique of package managers

#64

Post by Octoth0rpe »

gingerBill wrote: post #62
Octoth0rpe wrote: post #4

> Each dependency is a potential liability. I mean, sure. So what does the solution look like? From my perspective it looks like a tool that is able to update your dependencies so that you can easily pick up bug fixes in your dependencies, which sounds an awful lot like a package manager. > JavaScript is great example of this as there are multiple different package managers for the language (npm being one of the most…

> So what does the solution look like? There are no solutions, only trade-offs. And the point is that not everything needs to be, nor ought to be, automated. And package managers are a good point of this. And yes, a language with an ill-defined concept of a package in the language itself is a problem of the language, but the package managers are not making it any better.

> And yes, a language with an ill-defined concept of a package in the language itself is a problem of the language, but the package managers are not making it any better.

If a language does not provide a definition of a package but a package manager _does_, then I would say that that package manager did make that aspect of the problem better.

Re: A critique of package managers

#65

Post by gingerBill »

Octoth0rpe wrote: post #23
Sesse__ wrote: post #14

Earlier quoted context omitted.

> I mean, sure. So what does the solution look like? Obviously taking on fewer such liabilities?

The article specifically excludes this as _the_ solution to the problem: > I am not advocating to write things from scratch. and is clear in its target: > That’s my general criticism: the unnecessary automation. Yes, fewer dependencies is a solution, but it does not seem to be the author's position.

That is my position... again, I am not sure how you got this conclusion from the article.

The "I am not advocating to write things from scratch" is more of a caveat to the people I know will comment NIH nonsense rather than anything productive.

But yes, my position is minimize dependencies and slow and carefully vet them too, and do not automate this process.

Re: A critique of package managers

#66

Post by account42 »

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.

Re: A critique of package managers

#67

Post by seba_dos1 »

sombragris wrote: post #35

> How do I manage my code without a “package manager”? [...] Through manual dependency management. Slackware Linux does precisely that. I'm a Slackware user. Slackware does have a package manager that can install or remove packages, and even a frontend that can use repositories (slackpkg), but it does have manual dependency resolution. Sure, there are 3rd-party managers that can add dependency resolution, but they do…

Sounds like "alias dpkg=dpkg --force-depends"?

Re: A critique of package managers

#68

Post by seba_dos1 »

alexvitkov wrote: post #63
adev_ wrote: post #56

Earlier quoted context omitted.

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

> 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. If you're writing an ADAS system, and you have a "dependency tree" that needs to be "resolved" by a package manager, you should be fired immediately. Any software that has lives riding on it, if it has dependencies, must be certified against…

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.

Re: A critique of package managers

#69

Post by gingerBill »

Octoth0rpe wrote: post #64
gingerBill wrote: post #62

Earlier quoted context omitted.

> So what does the solution look like? There are no solutions, only trade-offs. And the point is that not everything needs to be, nor ought to be, automated. And package managers are a good point of this. And yes, a language with an ill-defined concept of a package in the language itself is a problem of the language, but the package managers are not making it any better.

> And yes, a language with an ill-defined concept of a package in the language itself is a problem of the language, but the package managers are not making it any better. If a language does not provide a definition of a package but a package manager _does_, then I would say that that package manager did make that aspect of the problem better.

It makes it worse in my opinion, not better. Because it leads to the problem that other package managers don't agree on what a package is, and it might even lead to the need for an external build system to co-ordinate all of it too. It's a never-ending problem, and is now even worse.

Re: A critique of package managers

#70

Post by gingerBill »

spacebanana7 wrote: post #2

> "This is the automation of dependency hell. The problem is that not everything needs to be automated, especially hell. Dependency hell 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. This the wrong thi…

> Getting rid of npm and doing things manually won't make building SPAs have fewer dependencies, build would be incredibly slow and painful.

Honestly, I don't think this is true in the slightest. Rather, I hypothesize that people want to use such tooling and think the alternatives are slower, which I don't think is true.

If people actually did use fewer dependencies, people would have actually have websites that didn't take ages to load and were responsive.

So the existing ecosystems are just bad.

Post reply on HN