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.
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
thanks @TLATER I guess you are referring to this ticket: https://github.com/NixOS/nix/issues/4744
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.
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.
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.