My painpoints with flakes

21

I did notice that it only needs to be staged and not committed (maybe this is a bug?). Still seems a pretty funny requirement to me. If it’s not actually needed to be committed then where are we going with this? Seems like a song and dance over nothing.

22

I wasn’t aware that I can unstage/stage during the execution of those hooks. That mighht indeed be a viable solution for me.

Even though I had to hook that into our lefthook workflow without touching the YAML file or damaging the hookfiles created by lefthook…

23

The reason it needs to be staged is that flake evaluation will only look at files that are tracked by Git. Note that it’s the content of the file in the worktree that counts, not the staging area. In particular, you can git add -N the flake.nix file and it’ll be just fine, at least until the next commit.

While I’m at it, my solution when working with a project that does not provide a devshell is usually to put my custom devshell higher in the file hierarchy and to store the project repository under it. It works well with direnv which I use and also allows to share devshells between related projects and generally decouple devshells from projects. (Admittedly that might not be the original vision for devshells)

3 Likes
24

Very helpful, thanks!

The from attr in nix.registry definitions can be left out for indirect entries, so you can simply write:

registry = {
  self.flake = inputs.self;
  nixpkgs.to = {
    owner = "NixOS";
    repo = "nixpkgs";
    rev = inputs.nixpkgs.rev;
    type = "github";
  };
};
25

I use this:

registry = lib.mkForce({
  pkgs.flake = selfFlake;
} // lib.mapAttrs (names: flakes: { flake = flakes; }) inputs);

where selfFlake is the self of outputs in flake-parts.

Then I defined legacyPackages = (getSystem system).allModuleArgs.final; so pkgs will be the same variable I’m using in system flake.