Could be areas of improvement as well

  • ck_@discuss.tchncs.de
    link
    fedilink
    arrow-up
    2
    ·
    1 year ago

    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.

    • jeffhykin@lemm.ee
      link
      fedilink
      arrow-up
      3
      ·
      1 year ago

      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.