> Python has notoriously terrible dependency management. It's a pretty low bar.
That's subjective. In my mind it's the only one that makes any sort of sense and isn't a freaking nightmare to use.
That's subjective. In my mind it's the only one that makes any sort of sense and isn't a freaking nightmare to use.
I remember looking in apt for nodejs one time and the version it had was about 5 years out of date, and it was missing all sorts of quality of life features that I had long since taken for granted (like promises). And of course, half of the packages in npm failed to run at all as a result. It was a complete non starter. Maybe I should have searched apt for ancient versions of common JavaScript libraries from a similar vintage? Then I could install them system wide. Yay. And what would all that extra hassle get me? A JavaScript program that would only work on one crusty Linux distribution. Which is strictly worse than what nodejs ships with out of the box: npm. Up to date packages. Modern JavaScript. And compatibility a mile wide.
And I could tell the same story with rust and cargo, and plenty of other languages.
Apt really makes no sense at all to use in this context. Maybe it’s fine to install X and gvim. But that’s about it.
If Debian really wants to mirror npm and cargo and other languages’ package managers, why don’t they just automate it, and add the hundreds of thousands of packages en masse?
Manually adding specific versions of packages from npm and cargo sounds like a massive waste of human effort. At best it will only ever produce a pale imitation of the real package repositories. I just don’t see the point.
If anything you usually have fewer problems with newer toolchains, because new features get used by your dependencies. The version of rustc or nodejs that Debian considers “stable” won’t be able to run a lot of software that I want to run.
And despite the name, “unstable” Debian is still usually 6 months behind the latest version of most packages. That’s an eternity for new things like Zig.
This is what Debian's Stable name means: that, once released, the operating system remains relatively unchanging over time.
> That’s an eternity for new things like Zig
So why isn't Zig making sure that their latest releases are available in Debian Sid? Anyone can be a Debian Maintainer, and if they don't want to invest their time in it, they just need an existing DM to sponsor their uploads.
As for why don’t the zig developers become official Debian maintainers, gentoo maintainers, redhat maintainers, FreeBSD maintainers, homebrew maintainers and so on - well, probably because they’re too busy making zig. There are way too many unix package managers to support without help. Especially if doing so requires joining mailing lists, manual testing and so on. I wish there was a way to automate making all those packages across different unix distributions, but I can see why that’s a hard problem.
Longer answer: In Debian's arrangement, the idea is that the distribution moves together, so it doesn't have a native idea of "fast moving packages on top of slow moving base packages". There are other systems where this isn't the case; AUIU you can run bleeding-edge packages on a stable FreeBSD base system (largely because the BSDs have a very strong separation of the base OS from everything on top), and NixOS is quite happy, especially with flakes but you could do it other ways, to go as far as "start with stable NixOS but then add packages X, Y, Z from unstable, and don't provide libFoo at all in a global context but provide libFoo 1.0 to package A, libFoo 2.1 to package B, and libFoo 3.0g straight from git for package C". But in Debian, the equivalent is probably running a newer version in a chroot or container, yes.
There's two problems with that: many tools no longer have multiple development lines, which means that Debian can't keep its stable releases secure without manual backporting effort, and upstream developers don't care about getting their software in Debian. This means that Debian unstable already lags behind, as you notice, but also that the freeze-before-release takes longer than necessary. But in my view, those are mainly ecosystem problems, not just Debian problems.
what is the constructive way forward? treat script language development and its packaging in a different way than OS base setup.
And rust is very much not a scripting language but it’s in exactly the same boat. Actually it’s probably worse because async and http support isn’t built in to rust’s standard library. A simple hello world web server with tokio and serde will probably have on the order of 40 dependencies in the dependency tree, not to mention rustc and cargo. How many of them do you think are in apt? Maybe none since, contra Debian’s policy, the final build result is statically linked anyway. The rust compiler doesn’t support dynamic linking of rust dependencies.
The reality is that apt simply doesn’t provide a stable, useful, modern software development ecosystem. The task of providing a “stable” version of rustc or nodejs is these days the responsibility of the rust and nodejs projects - which both have CI with incredible testing infrastructure. And the effect of that is that the latest stable versions are going to work more reliably to run real JavaScript and rust programs than whatever crusty version Debian ships.
And that disharmony between what Debian wants and what developers want causes real problems when shipping software to end users, and when deploying software to servers.