I’ve been working on my configuration for a while now using flakes. I can already understand the appeal of flake-parts, and my configuration has always been spread out across multiple files according to specific features. ATM I don’t really have any good modules to share, but what’s your opinion?

  • CorbinEnglish
    3·
    16 hours ago

    I don’t really like flake-parts or flakelight. I think that part of this is sheer brutalism (I don’t mind writing bare Nix) but part of it is a desire to not rely on flakes which don’t carry their own weight, following Wirth’s principle for compilers.

    That said, github:numtide/flake-utils does carry its own weight by managing multiple system values, especially in flakes that support more systems than upstream nixpkgs, and I’ve found myself using it in nearly everything; flake-utils makes it fairly easy to have leaf packages that are e.g. supported on both amd64 and aarch64. I know flake-parts does this too, but not in a way I enjoyed.

    I just noticed that you said “my configuration.” A machine, perhaps? My NixOS configuration is split into over a dozen NixOS modules and each machine has a list of included module files. I’m not using any flake-management tools for that flake; each machine has a hardcoded system and (like sibling comment from @[email protected]) they’re all crammed into one big flake.nix so that the machine hostnames line up correctly when using the flake in argv:

    $ sudo nixos-rebuild switch --flake git://git.example.local/one.big.flake.git

    Seems facetious at first, but it facilitates automatic updates via flakes, just like with classic channels.

    • adeptEnglish
      2·
      13 hours ago

      I don’t really like flake-parts or flakelight. I think that part of this is sheer brutalism (I don’t mind writing bare Nix) but part of it is a desire to not rely on flakes which don’t carry their own weight, following Wirth’s principle for compilers.

      How can you say this and still use flake-utils? All it does is manage your systems. You can write your own one-liner for that

      eachSystem = f: lib.genAttrs systems (system: f nixpkgs.legacyPackages.${system});

      Where systems is automatically supplied as a flake input (I think), or you can supply your own list of systems to support. You can then use it like this:

      devShells = eachSystem (pkgs: {
    default = # your devshell
}

      You can of course modify eachSystem to have more function parameters other than pkgs.

      See this blog which initially inspired me not to use flake-utils

    • bijectivehomomorphismOPEnglish
      2·
      16 hours ago

      Hey thanks, this is the sort of perspective I was looking for. As far as you’ve revealed, I’m pretty sure we have nearly the same setup.

      I wanted to see if flake-parts would be any enhancement, but it seems not since I’m also managing servers with along with my personal huge flake. I’m working on moving git-crypt out of my config so I can rebuild it straight from git, but I can’t find a way to declare my email in secrets (sops-nix you’re good at everything but…not trivial secrets)

  • algernon@lemmy.mlEnglish
    1·
    21 hours ago

    I used to use flake-parts, but I organize my flakes in a very different way (I generate a single, bigass flake.nix out of tiny org files), and found that frameworks like flake-parts and flakelight just get in the way. I suspect they’re useful if you’re working with Nix directly, but… I don’t like Nix (the language), so I do my organization outside of it.

  • PartiallyApplied@lemmy.worldEnglish
    2·
    2 days ago

    I really like it for devshells which is really all I use Nix for. Flake-parts automates so much boilerplate and improves the error messages so much compared to standard flakes. Definitely worth the time investment imo