| > No, I think it's a very sensible assumption. The problem is it's an "assumption" that is rarely easy to correct when it's wrong. > As far as I can see, virtually every GNU/Linux OS has shared libraries in /use/lib, and it even has crude support for versioning. If that were a satisfactory assumption there would be no need for sledgehammer solutions like docker. > it even has crude support for versioning. which is extremely unstandardised and frequently goes very wrong and will end up compiling against a mismatched set of headers and libraries. > Nix's approach is a break from the norm, so really it has the responsibility of maintaining compatibility. It doesn't really have any responsibility for anything apart from doing what its users want from it. And by and large it does that. > the existing standard Python tools everyone uses The "existing standard python tools" (pip, virtualenv, pyenv, tox...) are ~5 different attempts at solving the same problem, but each time failing to do so, giving rise to yet another tool. Properly applied, Nix can address all of them. It really doesn't sound like you want Nix at all - you appear to be arguing for the de-facto standard approach from the last 2-3 decades, which is not what Nix is. It is a deliberate departure from that. These design decisions that appear to annoy you aren't arbitrary choices that Nix people made to be difficult, they are core to how Nix works. If you want something that will present a facade that it's a linux system from the last 2 decades while still appearing to give you some of the advantages of isolated/pseudo-reproducible environments, what you want is docker. |