I'm very thankful for the Debian team's efforts to include most of my most commonly software packages in their repo. Out of all the differences between me and my colleagues workflows on MacOS and windows, this is the most impactful one. I don't remember the last time I had any kinds of dependency issues. I keep updating my packages when I log on and there are no version and/or dependency issues whatsoever.
A critique of package managers
71–80 of 220 posts
Re: A critique of package managers
#72> "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…
There already is a (partial) solution to dependency hell: Nix. It will at least massively help prevent things from breaking unexpectedly. It won't prevent you from having to cascade a necessary upgrade (such as a security fix) across the entire project until resolution/new equilibrium is achieved. My solution to the latter is simply to try to depend on as few things as possible. But eventually, the cancer will overta…
Nix isn't a solution to the problem of package managers. It just a better way to package management system, which thus makes it easier to go to dependency hell. So I'd argue it puts fuel on the flames.
The solution is just to depend on less and manage them manually.
Re: A critique of package managers
#73Earlier quoted context omitted.
> 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.
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.
Re: A critique of package managers
#74The argument here is (in brief) "Package management is hell, package managers are evil. So let's handle the hell manually to feel the pain better". And honestly speaking: It is plain stupid. We can all agree that abusing package management with ~10000 of micro packages everywhere like npm/python/ruby does is completely unproductive and brings its own considerable maintenance burden and complexity. But ignoring the de…
I am not sure how you got this conclusion from the article. > So let's handle the hell manually to feel the pain better This is far from my position. Literally the entire point is to make it clearer you are heading to dependency hell, rather than feel the pain better whilst you are there. I am not against dependencies but you should know the costs of them and the alternatives. Package managers hide the complexity, co…
> I am not against dependencies but you should know the costs of them and the alternatives.
You are against the usage of a tool and you propose no alternative.
Handling the dependency by vendoring them manually, like you propose in your blog, is not an alternative.
This is an over simplification of the problem (and the problem is complex) that can be applied only to your specific usage and domain.
Re: A critique of package managers
#75I 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,…
Rust’s big issue here is the anemic standard library. I think overall the strategy makes some amount of sense; since there’s so much crazy alchemy like depending on nightly, no_std, etc in Rust, including stuff in std has more downside in Rust than in a language that’s more stable like Go. But it’s annoying to have to deal with 3 different time libraries and 3 different error creation libraries and 2 regex libraries…
I agree, though also I note Python has an extensive standard library and isn't much better in terms of package sprawl.
Re: A critique of package managers
#76> 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"?
Perhaps; I'm not really knowledgeable on the ways of Debian.
Re: A critique of package managers
#77Earlier quoted context omitted.
I am not sure how you got this conclusion from the article. > So let's handle the hell manually to feel the pain better This is far from my position. Literally the entire point is to make it clearer you are heading to dependency hell, rather than feel the pain better whilst you are there. I am not against dependencies but you should know the costs of them and the alternatives. Package managers hide the complexity, co…
> I am not against dependencies but you should know the costs of them and the alternatives. You are against the usage of a tool and you propose no alternative. Handling the dependency by vendoring them manually, like you propose in your blog, is not an alternative. This is an over simplification of the problem (and the problem is complex) that can be applied only to your specific usage and domain.
It is an alternative, just clearly not one you like. And it's not an oversimplification of the problem.
Again, what is wrong with saying you should know the costs of the dependencies you include AND the alternative approaches of not using the dependencies?—e.g. using the standard library, writing it yourself, using another dependency already that might fit, etc.
Re: A critique of package managers
#78Earlier quoted context omitted.
How is this relating to the alleged inexperience of the original author? Not sure what do you mean.
The above comment is merely pointing out that a 10y+ experienced language designer can still have naive viewpoints on application development. Anyone who's built a non-trivial userspace application knows that realistically you'll have to reach outside a particular languages standard library in most cases to provide value without reinventing wheels. In other words: when someone's knowledge is disproportionately locali…
I don't buy it.
A guy designing and then implementing a programming language has a much bigger chance to put a lot of rational thinking into the tooling like dependency manager, than a typical language consumer, who can and often is easily falling into the languages emo wars.
Re: A critique of package managers
#79Earlier 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?
I know very few people using Hare, especially since it only works on "FOSS platforms". And I will still maintain that V is vapourware. They still have the same false claims on the website that they've had from the beginning for ~6 years.
Odin is "successful enough" so far. Also, you know about it, so that says something.
Re: A critique of package managers
#80Earlier quoted context omitted.
The above comment is merely pointing out that a 10y+ experienced language designer can still have naive viewpoints on application development. Anyone who's built a non-trivial userspace application knows that realistically you'll have to reach outside a particular languages standard library in most cases to provide value without reinventing wheels. In other words: when someone's knowledge is disproportionately locali…
I don't buy it. A guy designing and then implementing a programming language has a much bigger chance to put a lot of rational thinking into the tooling like dependency manager, than a typical language consumer, who can and often is easily falling into the languages emo wars.
> than a typical language consumer, who can and often is easily falling into the languages emo wars.
How is ginger bill excluded from this group? No one is more invested in a language than its creator(s).
Sure, he might have given it a lot of thought, but he came up with some completely bonkers conclusions. If you don't want dependencies, DON'T IMPORT DEPENDENCIES. Don't make your dependencies extremely hard to add.