I agree, though I think there are a couple pieces to the puzzle. Like, quite apart from the enormous convenience of new releases being available right away, and even being able to drop in a git URL and run your dependency off a branch while you wait for your upstream PR to merge, pip provides isolation between workspaces that apt has never been able to do natively because it's too generic— the closest thing is lightweight unshares, but those were years after virtualenv, require more ceremony to get going with, and may be isolated from the outside system in ways that impede productivity (there's also never really been a consistent tooling story for it, with having to cobble together debootstrap + whatever the chroot flavor of the week is).

But the biggest issue is when npm, cargo, etc showed how to include a dependency multiple times at different versions. Operating system package managers (other than Nix & friends) have no concept for how this could or would work. Pip has no story for it, and the various pip-to-apt bridges like py2deb and stdeb if anything just exacerbate the problem, by mixing your project's dependencies with those on your system.

Anyway, yes. Things were lost, 100%. But I don't think the system you want (isolation, version freedom, but with safe/vetted packages) is going to be something that's possible to evolve out of any of the current systems. It's got to be something that goes back to first principles.

> pip provides isolation between workspaces that apt has never been able to do natively because it's too generic

This is hardly a concern on production systems. It's been common practice for decades to deploy each service on a dedicated host, or at least a VM in order to have a degree of security isolation. [or a container if you don't care]

> npm, cargo, etc showed how to include a dependency multiple times at different versions

And this is why they cannot provide stable releases and security backports.

If you want security updates you can use Debian or pay $$ for SuSE or Red Hat or $$$$ for custom support from some tech companies, but they will mostly support one version per package.

The combinatorics explosion of packages times versions on archives like npm or pypi makes it prohibitively expensive to reliably patch and test every combination of packages and versions.

Debian has been pioneering reproducible builds and automated installation CI/QA and it still took a lot of effort to get there.

> I don't think the system you want (isolation, version freedom, but with safe/vetted packages) is going to be something that's possible to evolve out of any of the current systems.

I don't want version freedom: it's not attainable. It's not a software problem, it's a math problem.

> It's got to be something that goes back to first principles.

Any idea?

If you don't want or need version freedom, what is it about the existing deb/rpm ecosystems that don't work for you, either on their own or in conjunction with the various tools that bridge other ecosystems into them? (I'm a fan of dh_virtualenv, myself)

Or is your lament that the world as a whole is worse off because others have eaten of the fruit of systems like npm and pip?

The latter, albeit it's not "the world as a whole", but some tech bubble. Various large companies prohibit pip/npm/docker.

(and here I'm even getting downvoted for going against the hivemind)

I can only hope that after enough software supply chain attacks the industry will realize that distros were right all along.