this post was submitted on 18 Oct 2023
17 points (100.0% liked)

nixos

1496 readers
1 users here now

All about NixOS - https://nixos.org/

founded 5 years ago
 

Could be areas of improvement as well

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 10 points 2 years ago* (last edited 2 years ago) (14 children)

after spending +3 years getting experienced and reading a lot of the source code (getting past the documentation/learning-curve problem), I can say there are at least two fundamental flaws, with nixpkgs moreso than nixos:

(Edit: Added 0)

  1. The culture issue. See thread below

  2. The messy mono-repo was never desgined to be searchable. It might feel searchable to a newby, but many teams have dumped tons of effort and slapped together lots of hacks to make niche-package-versions even halfway searchable. Devbox is doing a good job of fixing this, but its not there yet.

  3. The monorepo design is unmaintainable/unscalable from a package maintainer standpoint. There's a ton of contributor burnout, there's no automated quality control on packages, to outsiders its not obvious how to report package-specific issues or how to edit/fix/contribute to a single package, and instead of 30min to publish a hello-world npm or cargo package, users need to make a PR on the core, and get it approved. Meaning publishing a hello-world package would get rejected anyways. The good news is flakes hub is fixing this, and I'm really excited for that.

The good is;

  • The pros still outweigh the cons. My projects from 3 years ago that I haven't touched still work (0 bitrot) first try, no manual install/setup needed.
  • people have put a ton of effort into nix. 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.
[–] [email protected] 2 points 2 years ago (3 children)

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.

[–] [email protected] 3 points 2 years ago (1 children)

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

  1. Is 100% pure (no stdenv)
  2. is versioned
  3. doesnt link/depend on all of nixpkgs

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.

[–] [email protected] 3 points 2 years ago (1 children)

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

[–] [email protected] 1 points 2 years ago

Oh cool! I didn't know about that. Maybe I can work eith the other person who is doing that.

load more comments (1 replies)
load more comments (11 replies)