after reading a lot of the source code and spending +3 years getting experienced, I can say there are at least two fundamental flaws:

The good is;

• people have put a ton of effort in. Its truely amazing how many things work in nix despite how absurdly difficult it is to get things working with nix
• it is pretty much as reproducable as it can be and nothing else is even remotely close.

I have to agree on those two cons. Contributing to nixpkgs is a major pain point for me. I don’t mind having to get PRs reviewed, but the speed and the lack of consistency have really put me of from doing that again. Quality control is also a major pain point. Nixpks supports a bunch of platforms and architectures, but anything other than tier 1 (x86_64-linux, gcc + glibc ) can and will just randomly break because maintainers and contributors don’t usually care for anything that’s not right in front of their eyeballs.

Personally, I avoid touching the monorepo like the plague and stick to putting everything into flakes if possible.

Agreed, flakes are the way. Its just making them searchable hasn’t been easy/realistic until recently.

Also I feel like flakes are kind of tainted by always pulling in nixpkgs as a massive dependency chain. I think there should be a standard library separate from the packages, and nixpkgs.lib is 80% pure functions. So I’ve been working on making a “lib” flake that

I know it still won’t be practical to avoid depending on nixpkgs, but I think its a step towards breaking up nixpkg into organized/managable chunks.

I actually think I have seen this being discussed, but does not seem to be at the RFC level yet. Probably drowned in all of the flakes vs monorepo discussions.

One prerequisite for this that’s in the making are flake versions: github.com/NixOS/rfcs/pull/158