[williamvds]

Thanks for the great write-up. As someone who somewhat recently got into Nix I've struggled with many of the same problems.

With the whole "your system is read-only" bit, I'll add that Nix can make trial and error editing of config files quite tedious. Editing and reapplying the configuration is fast, but not as fast as editing a file and `systemctl restart`ing the service in question.

On development environments I've also had similar problems. My workplace uses a combination of Python and C++. While Python has an established package management system, C++ is still in the early days. The traditional is just use what your OS provides, but the production OS is different from the development OS, the former being much more "stable" (and therefore with older package versions) than the latter. This has caused plenty of headaches with features not being available, and is holding us back from using newer C++ features, or even adding dependencies easily.

Being keen on Nix, I've been testing out using it locally for dependencies.

With C++ it mostly works. Some annoyances have been packages not providing CMake or pkglib config files. Some packages don't quite have all the possible features enabled, and it's not trivial to enable them (I struggled with arrow and liborc).

Then comes Python, which introduces the same nightmares which the author experienced. Python packages that use system shared libraries are troublesome. The buildUserFHS solution seems like the right approach when mixing and matching, but it introduces a few more problems (the details of which elude me right now).

An additional problem is portability. Theoretically one could use `nix bundle` to ship whole applications, but a shared library is a different matter. We've got a Python module written in C++ module, I'm not sure a module built by Nix would be compatible with the host's Python, given the libstdc++ differences and so on.

This struggle is topped with the fact I'm the one going against the grain, trying to sort out the issues I hit, for my own purposes only. I do hope I manage to prove to myself that it's a tenable approach, and eventually can propose it to the wider team. But for now I know it's a dream.

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