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

11–20 of 220 posts

Re: A critique of package managers

#11

Post by zdragnar »

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…

Yeah, yarn and co came about because npm was slow, buggy and didn't honor its own lockfile.

Nowadays it is mostly improved, and the others differentiate by enchantments to workspaces (better monorepo support) or more aggressive caching by playing games with where the installed packages physically exist on the system.

The core functionality- what a package is- has always been the same across the package managers though, because the runtime behavior is defined by node, not the package manager.

Re: A critique of package managers

#12

Post by 1GZ0 »

smw wrote: post #5

"When using Go for example, you don’t need any third-party libraries to make a web server, Go has it all there and you are done." Fine, now what if you need to connect to a database, or parse a PDF, or talk to a grpc backend. What a hilariously short-sighted example. To me, this whole article just screams inexperience.

The Author isn't arguing for not using third party dependencies. He's arguing for developers to be more conscious of the dependencies they use, by manually vetting and handling them. That screams "I've been down the package manager route and paid the price". Not inexperience.

Re: A critique of package managers

#13

Post by Sesse__ »

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.

You don't think making adding dependencies incredibly slow and painful would make people have fewer of them?

Re: A critique of package managers

#14

Post by Sesse__ »

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…

> I mean, sure. So what does the solution look like?

Obviously taking on fewer such liabilities?

Re: A critique of package managers

#15

Post by bluGill »

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…

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

If only it where that easy.

Often the update isn't source compatible with the package that uses it so you can't update. There are some projects I use that I can't update because I use 6 different plugins, and each updates to the main project on a different schedule on their own terms - meaning the only version I can use is 10 years out of date and there appears no chance they will all update. (if this was critical I'd update it myself, but there are always more important things to work on so I never will in practice)

Sometimes a package will change license and you need to check the legalese before you update.

Sometimes a package is hijacked (see xv) and so you really should be doing an audit of every update you apply.

Re: A critique of package managers

#16

Post by Ygg2 »

kunley wrote: post #10
smw wrote: post #5

"When using Go for example, you don’t need any third-party libraries to make a web server, Go has it all there and you are done." Fine, now what if you need to connect to a database, or parse a PDF, or talk to a grpc backend. What a hilariously short-sighted example. To me, this whole article just screams inexperience.

Inexperience of an author who develops quite successful programming language for like 10 years? Quite a bold statement. Actually his perspective is quite reasonable. Go is in the other part of the spectrum than languages encouraging "left-pad"-type of libraries, and this is a good thing.

I've seen plenty of intelligent people acting pretty stupid.

As my psychology professor used to say. "Smart is how efficiently use your intelligence. Or don't."

So someone pretty low IQ can be smart - Forrest Gump. Or someone high IQ can be dumb occasionally - a professor so very attuned to his research topic at expense of everything else.

Re: A critique of package managers

#17

Post by pipes »

1GZ0 wrote: post #12
smw wrote: post #5

"When using Go for example, you don’t need any third-party libraries to make a web server, Go has it all there and you are done." Fine, now what if you need to connect to a database, or parse a PDF, or talk to a grpc backend. What a hilariously short-sighted example. To me, this whole article just screams inexperience.

The Author isn't arguing for not using third party dependencies. He's arguing for developers to be more conscious of the dependencies they use, by manually vetting and handling them. That screams "I've been down the package manager route and paid the price". Not inexperience.

But titled the post "package managers are evil"

Re: A critique of package managers

#18

Post by microtherion »

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…

Some years ago, I had to reproduce a neural model build that had only been done previously by a single colleague on her laptop, not using a package manager.

Part of my reproducing the build was to conduct all the library downloading in a miniconda environment, so at the end I had a reproducible recipe.

Is the original author seriously claiming that anybody was better off with the original, "pure" ad-hoc approach?

Re: A critique of package managers

#19

Post by Ygg2 »

Sesse__ wrote: post #13
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. You don't think making adding dependencies incredibly slow and painful would make people have fewer of them?

You would decrease number of dependencies yes. However your dependencies or your code would then become huge.

Same number of lines but in fewer dependencies.

Re: A critique of package managers

#20

Post by spacebanana7 »

Sesse__ wrote: post #13
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. You don't think making adding dependencies incredibly slow and painful would make people have fewer of them?

In the context of my team, us getting rid of npm wouldn't change the whole SPA ecosystem. Or the various requirements we have that effectively mandate SPA like applications.

But in the context of newer ecosystems or ones that are more tightly controlled things might be different. For example if apple massively expanded the swift standard library and made dependency management painful, iOS apps might end up having fewer dependencies.

Post reply on HN