I'll say it again: why does each language need its own package manager? Why not generalize it to delivering files from various online sources, with a thin layer of glue for module loading that is language-specific.
The downside is, as you found, they're usually out of date. The upside is that if you get a Python program added to Stable, you can rest easy knowing that end users won't have to battle dependency hell to get it running.
*: This does not apply if you've made a FrankenDebian by combining Sid and Stable, or other such things. You're on your own, good luck.
Perhaps we should standardise "languages" too: all compiled programming do be done in N-- and all interpreted programming in Piffle. Thou shalt not touch machine code and that unless thou be a priest
... no of course not!
A "standardised" package manager is close to the least of our worries in IT land. Today I updated a .deb based server software on an Ubuntu box and used a built in update mechanism to update its client software - this is a MinIO instance. I'm not worried that it will fall to bits.
Anyone with a Windows box with a worrying number of Visual C++ runtimes might like to remove the lot and install the latest from here: https://learn.microsoft.com/en-us/cpp/windows/latest-support...
A general package manager that only sees packages as directory blobs would not need to be that complicated. In fact I don’t think npm has this deep knowledge about JavaScript either, it just put stuff inside node_modules and calls it a day.
That said, it would be great if more projects adopted Bazel, its biggest problem today is adoption, forcing you to convert any dependencies to make it Bazel compatible.
Because the job of a package manager is complex and humanity hasn't figured out a universally satisfactory solution.
Research and development are ongoing, and the state of the art is at a level of complexity that I'd compare to a doctoral project or something, requiring one to throw away tons of the abstractions they know and learn a lot from scratch (nix).
The benefit of CDNs used to be that you could cache a library for use on multiple domains but I don't think that works anymore.
These don't seem bad for dependency-free libraries, but they won't warn you about incompatible package dependencies.
SMACK
Somewhere in an alternate universe, there's a better timeline.
But I also think it’s been permanently tainted due to a constantly shifting ecosystem that can’t settle down, and a user community that is constantly chasing new shiny things.
Dependency management is a disaster in a ton of ecosystems. It is often a different set of disasters than what npm has, but it isn't like this is a solved problem everywhere else and it is just the js ecosystem that sucks. NPM is made marginally worse by the poor standard library in JS but I don't think the problem is fundamentally attached to the language in any meaningful way.
And the push to use JS for backends was not "we want this to be a serious language" but was instead "well, we are already using JS for frontends so it'd be nice from a practical standpoint for hiring and training to be able to use the same language and ecosystem for backends too."
I guess the real answer is because it's a lot of work to maintain packages and versioning and there is space for multiple solutions.
By being hermetically sealed, the community can make progress on testing, repeatability, and lots of things that would become incredibly difficult if you introduced anything else into the mix.
Moreover, each language gets to innovate in its own way. Cargo is fantastic and fits the needs of Rust quite well. Custom builds, cross compiling, codegen, ...
This is not what they’re arguing for.
> Custom builds, cross compiling, codegen, ...
That’s great, none of that is “package management”.
The point is, every language has a way to specify dependencies, find the correct versions, and download them recursively. Could that piece be made generic?
Tight coupling matters.
> Could that piece be made generic?
Semver has different meanings to different languages based on compiler versions.
Some languages want 100% build reproducibility and hermeticity, and some languages will never get there.
Some languages permit yanking.
Some languages allow binary distributions.
...
These decisions go very deep to the fundamental ethos of the languages themselves. I don't think we'd find any agreement.
Python is an example of a language that can (and historically has) done arbitrary things in package installation https://stackoverflow.com/a/43350802/2751619
I think things have improved, but you didn't used to be able to build a dependency tree without installing all packages and iirc there was a dependency resolution case where pip would download every version counting backwards until one happened to install
I know way too many coders and firms taking a "throw stuff to the wall and see what sticks" approach to software. The phrase "just solve the problem and move on" comes to mind. These places are often in firefighting mode and cannot connect the dots for some reason.