I do not have a good idea, but other ecosystems evolved much more sane in the realm of packaging. While not ideal, Go has done a fairly good job - and the "module" operations are instant - which they should be.
Sketch for python: Create a ~/.cache/python/packages directory. Manage all dependencies there. Make the python interpreter "package aware" so that required dependencies are read off a file from the current project (e.g. "py.mod") and adjust "system path" accordingly and transparently. Or something along those lines.
No extra tool, a single location, an easy to explain workflow (add a py.mod file, add deps there with versions, etc).
I'm just thinking out loud, but it does not need to be hard.
Are you saying "put the different version of every dependency you need in there if you have to"?
Because I don't think package managers are ready for that, they usually like to have one version installed per package.
That's on them. Other language package managers can do it...
now the build tooling still needs some work around versions but its only a minor problem generally as much as it annoys me personally.
The HN bubble can be amazing sometimes.
The burden of updating multiple copies of the same library across many packages grows exponentially and is simply untenable for distributions.
If you can find an army of volunteers to do that, distributions would love their contributions.
This hasn't happened in the last 20 years. I'd love to be proven wrong.
> If there are no resources to carry that burden, then the only option seems to be to wait for an updated release from the upstream, whenever that arrives.
No, most upstreams do not backport security fixes. And switching to a newer release is not an option if you want to provide stability to users.