Native dependency cache

As a tangent, I think these two technological approaches to code reuse can be combined as well. Going back to SuSE JeOS and OBS, the traditional packaging systems can help build containers and manage larger conglomeration of software bigger than one library or app, but they do need to grow to better bridge and encompass the hard work and knowledge built into the language-specific package managers like pip, npm, cpan, etc so that you can have one tool that is capable of showing the full dependency tree for a larger multi-language, multi-project system. cpanspec is pretty good, you can build anything from cpan with high fidelity of the dependency requirements known to cpan with only occasional fixes needed, this is not my experience with pip and setuptools as the bridge between ecosystems is rudimentary and the chance of irreconcilable dependency conflict is too high, which is why virtualenv contains dependency management for the single runtime much like how OCI containers can do for other apps.

For systems like how go and Rust manage code reuse the bridge tooling could be even more useful, providing a standard way to document build dependencies even when the result is a static binary without dynamic linking to inspect. Ask the package manager what software in the repo was built with git@git.example.org/libfoo.git and what commits were used, because the package format can be made to save that info reliably, so you can patch yourself or help the distro automatically do what needs to be done. OpenBuildService already does d
full CI and dep tracking across multiple languages for an entire distro of software using RPM spec as the CI language. You can do very slick things for one project on one language with the standard tools for that language, but the distro world has built great tooling for managing a whole runtime that could be made even better, even if the end result is building an OSTree or Flatpak image.