[ris]

> Then comes Python, which introduces the same nightmares which the author experienced. Python packages that use system shared libraries are troublesome.

The nightmares come from pypi packages and their assumptions that e.g. the particular version of `libfoo.so` that happens to be in your `/usr/lib` at the time of installation is the one you need it to link against, which is a very crass assumption in 2023. Nix doesn't hide you from this. But it's quite straightforward to write your own nix packages based on upstream python packages which should work fine alongside other nix packages.

By and large, nix does not play particularly well with other package managers, because the nix view is that it's absurd having 7 different package managers fighting for control of the same system.

[williamvds]

> which is a very crass assumption in 2023

No, I think it's a very sensible assumption. 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.

When these assumptions break with Nix, I'll grumble about it, but I won't blame it on the original package. Nix's approach is a break from the norm, so really it has the responsibility of maintaining compatibility.

> But it's quite straightforward to write your own nix packages based on upstream python packages

Things break down when you have to stick to specific versions of packages, at which point creating/overriding nixpkgs quickly becomes untenable. My idea is to use Nix to complement the existing standard standard Python tools everyone uses.

[ris]

> 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.

[yellowapple]

> because the nix view is that it's absurd having 7 different package managers fighting for control of the same system

And addresses that by becoming the 8th different package manager fighting for control of the same system, a la https://xkcd.com/927/

[ris]

Except the entire argument here is that it doesn't cooperate very nicely with other package managers so I'm not sure how your point holds together.

[yellowapple]

Except not a single other one of those package managers cooperates very nicely with other package managers either so I'm not sure why you'd believe my point doesn't hold together.