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

111–120 of 220 posts

Re: A critique of package managers

#111

Post by pessimizer »

morsecodist wrote: post #34

In general, I think the dependency hate is overblown. People hear about problems with dependencies because dependencies are usually open source code used by a lot of people so it is public and relevant. You don't hear as much about problems in the random code of one particular company unless it ends up in a high profile leak. For example, something like the heartbleed bug was a huge deal and got a lot of press, but i…

> imagine how many issues we would be in if everyone was implementing their own SSL.

No, the alternative is to imagine how many issues we would be in if every project pulled in 5 different SSL libraries. Having one that everybody uses and that is already installed on everyone's system is avoiding dependency hell. Even better if it's in stdlib.

Re: A critique of package managers

#112

Post by dismalaf »

tialaramex wrote: post #48
kunley wrote: post #10

Earlier quoted context omitted.

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.

Is it "quite successful"? How would I distinguish such a "quite successful" language from say Hare or V or are these all "successful" in your mind?

There's commercial software produced in Odin that has made money. Not sure the same can be said of Hare or V.

Re: A critique of package managers

#113

Post by marcelr »

i had this idea for vendor based “package manager”

what if packages were meant to be read, and config was set inside the file directly

what if we transitioned to think of packages as templates, rather than generic black boxes

i think it would drastically reduce dependencies, package complexity, and improve understanding

Re: A critique of package managers

#114

Post by lou1306 »

marcelr wrote: post #113

i had this idea for vendor based “package manager” what if packages were meant to be read, and config was set inside the file directly what if we transitioned to think of packages as templates, rather than generic black boxes i think it would drastically reduce dependencies, package complexity, and improve understanding

You can do this in Python, today. Whenever you need a package, just add its code in a directory under your project's root. And good luck.

Re: A critique of package managers

#115

Post by bsder »

> SDL3 might fix it all but the time to integrate SDL3 would be the same time I could write it from scratch.

The Programmers’ Credo: we do these things not because they are easy, but because we thought they were going to be easy

Re: A critique of package managers

#116

Post by dismalaf »

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.

And if the language does provide the definition?

Re: A critique of package managers

#117

Post by ChadNauseam »

epage wrote: post #8

> Dependency hell [0] 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. [0] https://en.wikipedia.org/wiki/Dependency_hell I find it strange that they use a term with a common meaning, link to that meaning,…

Same. The first thing I thought was "wait a second, that isn't dependency hell".

The second thing is that their version of dependency hell - having lots of dependencies introducing lots of bugs that you would not have written - is not my experience. 99% of the time, my bugs are in my own code, lol. Maybe once you become a much better programmer than me, you stop writing bugs in your own code and instead start having to deal with bugs in the PNG parsing library you depend on or something, and at that point writing your own PNG parsing library becomes a good use of your time. But I'm certainly not at that point.

I've had to fix bugs in dependencies of course. Here is one I fixed yesterday [0]. But it's much closer to the exception than the rule.

[0]: https://github.com/sanity/pav.rs/pull/4

Re: A critique of package managers

#118

Post by wpollock »

Octoth0rpe wrote: post #37
bluGill wrote: post #15

Earlier quoted context omitted.

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

I agree with all of the problems that you're highlighting, but would say that all of those problems exist whether or you're doing manual dependency management or using a package manager. The solution IMO (which is non-existent afaik) would be to integrate some kind of third party auditing service into package managers. For example, for your npm project you could add something like this to your package.json: ` "requir…

The Boost library went the audit route, but AFAIK, few other repositories (or libraries) have done that. I believe it's a cost and lack of manpower that prevents that.

You may not have the time to audit dozens/hundreds of dependencies pulled into your projects, but there's still something you can do. For Rust/Cargo, you can run tools that check every dependency against a vulnerability list. As you have source of dependencies, you can also run static code analyzers/auditors to scan for code smells, lack of unit tests, etc.

For Java, I use the OWASP plug-in of Maven to check dependencies for security vulnerabilities. I bet other languages' package managers/build tools have similar plug-ins.

Some auditing is better than none at all. You shouldn't do no checking just because you can't full auditing!

Re: A critique of package managers

#119

Post by izzylan »

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 downloaded version 2.7.3-2 but the version I use is 2.7.3-1.

Re: A critique of package managers

#120

Post by gingerBill »

bsder wrote: post #115

> SDL3 might fix it all but the time to integrate SDL3 would be the same time I could write it from scratch. The Programmers’ Credo: we do these things not because they are easy, but because we thought they were going to be easy

We've effectively written all of this already because of the amount of fixes we've had to do to the SDL2 code. So yes, we know what we are doing.
Post reply on HN