13
Thoughts on flake-parts? (programming.dev)
submitted 2 years ago by to c/nix@programming.dev
8 comments fedilink hide all child comments
 

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?

all 8 comments

sorted by: hot top controversial new old
[–] 5 points 2 years ago (2 children)

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 @algernon@lemmy.ml) 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.

  • permalink
  • fedilink
  • source
  • hideshow 4 child comments
    •
  • [–] 3 points 2 years ago (1 child)

    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

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 2 years ago

    I've come around to doing it this way too. systems is not automatically supplied as a flake input - you can get such an input like this:

    inputs = {
  systems.url = "github:nix-systems/default";
  # ...
};
outputs = { self, nixpkgs, systems }:
  let
    eachSystem = f: lib.genAttrs (import systems) (system: f nixpkgs.legacyPackages.${system});
  in
  {
    # ...
  }

    The handy thing about importing another flake to get a list of four strings is that anyone consuming your flake can override that input in case they want to use a system that isn't included in your original flake. There is more information at https://github.com/nix-systems/nix-systems

  • permalink
  • fedilink
  • source
  • parent
  • [–] [S] 2 points 2 years 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)

  • permalink
  • fedilink
  • source
  • parent
    • [–] 3 points 2 years ago

    @bijectivehomomorphism
    IMO, the best flake framework.

  • permalink
  • fedilink
  • source
    •
    [–] 2 points 2 years 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

  • permalink
  • fedilink
  • source
    •
    [–] 2 points 2 years ago

    I use https://github.com/nix-community/flakelight, since it requires even less boilerplate

  • permalink
  • fedilink
  • source
    •
    [–] 1 point 2 years 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.

  • permalink
  • fedilink
  • source
    •