In a flake, where to put a function that generates a derivation?

Help
1

I have a function like buildRustPackage (in my case mkCljBin, from clj-nix) which returns a derivation, exposed using a flake.

Currently, I have those functions in the flake outputs.packages, but that breaks some flake functionality, like nix flake check. Where should those functions be? I know about outputs.legacyPackages, but it feels wrong to put something new here. I also thought about putting it under outputs.lib, but I didn’t like it either because nix flake commands complain about lib being an unknown output attribute.

2

There’s no place for these currently. There’s an open ticket upstream about adding lib, but arguably that should be for pure nix functions, not derivations.

I’d personally probably use lib for the moment, but I think I’d actually like a builders attribute.

4 Likes
3

thanks @TLATER I guess you are referring to this ticket: https://github.com/NixOS/nix/issues/4744

1 Like
4

You can make it an arbitrary output but there’s no dedicated place aside from overlays.

Overlays are “where these fit” if you want to suppress warnings nix flake check but honestly I expose functions all the time. Sometimes I’ll call Nix recursively with an app if I want to write a file when generating Nix expressions.

Also, if you’re generating Nix files and you need “scale” or are sick of writing generators I have a collection of __toString implementations for this purpose you’re welcome to use.

1 Like
5

I think using legacyPackages could be reasonable. In

Eelco says that it is not called that because the contents are legacy, just because there is a problem with nested package sets and expensive evaluation.

2 Likes
6

Plus one for the builders output, as it is, there is nothing stopping you from just using it, and even writing a check for it. Personally I think it’d be nice if #5403 or something similar were merged so we could inform Nix of our extended API’s and optionally even enforce them.

1 Like