Which is a "standard" way of dealing with a custom lib for flakes

I have some functions that I use through my flake, I current declare a myLib attribute in my outputs, but I would like to know if there’s any standard way of doing a custom library or merging my functions with nixpkgs’ lib.

2 Likes

You’d put it in the lib attribute, which has been made an officially accepted attribute as of like nix 2.13. nix flake check will complain about myLib.

There is no standardization beyond the attribute name. Some people will tell you to use flake-parts or make an overlay. Some people will tell you that that’s heresy and defies the purpose of flakes, and you should do something like this:

outputs: { ... } @ inputs: {
  lib = {
    myFunction = args: inputs.something.lib.otherFunction args;
  };
}

… calling functions with args as needed for organization instead of building one massive flake.nix, of course.

A way to parameterize system never materialized, sadly, so you get to invent your own if you need that. lib.${system} was suggested, but since flakes generally haven’t found an accepted solution to this you’ll have to redesign this anyway. Another alternative is to make a legacyPackages.${system}.lib.

Personally I think there should be both a lib without system parameterization for utility functions, and a separate attribute with system parameterization for builders and such, so I’d probably prefer using legacyPackages until that materializes. I also am firmly in the camp of not overcomplicating flakes for no reason. But all of that is opinion.

3 Likes

I use the forAllSystems function to deal with system. Thanks for the explanation, indeed I was looking for a way to make nix flake check happy!