Python virtual environments

For instance, because containers, just like virtual environments (that may be seen as a lower form of containerization) only mitigate the issue, do not solve it.

As mentioned before if you write program A that depends on package B, which in turns depends on C at version Y and then you realize that you also need D which depends on C at version Z, then containers or virtual environments are not going to help.

But what I find weird is that versioned "libraries" or "packages", that is a simple solution that was invented together with shared libraries many tens years ago, which would cost very little to implement in a high level interpreted language and which would not preclude at all the use of containers or virtual environments did not make into Python that, for other things, does not seem to completely avoid rather complex solutions and their associated cost.

The funny thing is that the very language developers feel the need to introduce "naming" conventions to work around this limitation (e.g., because versioned packages do not exist, they end up attaching the major version number to the package name itself as in urllib vs urllib2). Same goes for extension packages on Pypi (e.g., gmpy vs gmpy2).