this post was submitted on 18 Oct 2023
17 points (100.0% liked)
nixos
1262 readers
3 users here now
All about NixOS - https://nixos.org/
founded 4 years ago
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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: https://github.com/NixOS/rfcs/pull/158
Oh cool! I didn't know about that. Maybe I can work eith the other person who is doing that.