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.
I hear ya but in practice that doesn't work well. For instance Ubuntu has (or had) .dpkg distributions for many popular Python and Perl libraries, installable via apt. We quickly learned never to use them because they were always out of date and often packaged strangely.
Debian (and therefore Ubuntu) Python packages are largely intended for system Python, that is, the version of Python that ships with the distro. If you install a package from a Deb-like repo, its dependencies will be present, and it will work* as intended.
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.
I'm afraid I didn't hear you last time (did I miss aught?)
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.
Delivering files is the easy part, integrating with the language tooling/buildsystem is the hard bit. Seemingly simple concepts like a dependency don’t translate neatly across languages.
Bazel is also 1.4 million lines of code which proves the point of how complex of an endeavor this is. Bazel has a mixed reputation due to that complexity and the overhead that comes with it, and is definitely not just a simple drop in replacement for a language's existing tooling.
Bazel does a lot more than just download packages though. It can also track dependencies down to individual file level and isolate build steps to assure they don’t have side effects. This is largely why it is so big and need to be language aware. Add remote build cache and lots of other stuff.
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).
What you're advocating is essentially the way Javascript originally worked, with the web itself serving as the "package manager." but one day someone decided Javascript needed to be a serious business language for serious business, and serious business languages use compilers and toolchains and have a package manager. And so here we are.
What’s in js that makes it different from any other language? Any other language would likely bend into <what you mean by that> form with enough users coming to it from the “web” direction. It’s just a law of big numbers.
Compared to other high-level languages, nothing, really. I actually really like JS for its intended purpose (or just as a way to learn programming).
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.
JS is a messy language. But I don't think that this is really fair.
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."
You don't have a runtime dependency if you just download the js to your server and write some script tags. You do have to do things manually and locally but you'd be surprised how robust that can be. Just vendoring scripts and not automating builds would solve like 99% of modern JS problems.
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.
I don't want anything in my Rust dependency tree depending on node packages.
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, ...
> I don't want anything in my Rust dependency tree depending on node packages.
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?
Some languages do all kinds of arbitrary things during package installation so the lowest common denominator is "the package manager can execute arbitrary code that does anything" unless languages change their designs to something more restrictive.
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 think about this one very often. I think it can even be generalized: "complex system problem seems intractable due to complexity... I know, I can simplify some bits of it by adding complexity to it".
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.
The world is simply too complicated for that, there is no way you would get the maintainers of rust, npm, deno, haskell, etc to all agree to one "package system to rule them all".
