Open lovesegfault opened 2 years ago
I was confused by this a number of times as well, but maybe all that's needed is a documentation update. After all, requiring overlays
to be an attribute set is a bit more versatile. That way, if there are multiple overlays inside, the user can pick and choose, and if one does want all the overlays, it's just a builtins.attrValues
away. The only issue I see with that is that maybe attrValues
puts them in an unintended order though :thinking:
I think overlays as attrs and as a list serve different purposes, and perhaps should be separate outputs altogether.
I see a list of overlays as just a handy way of exposing a "combined" set of overlays ready-to-use. In contrast, I see attrset of overlays as a way of exposing a set of overlays that may not even be meant to be used together.
You can work around this currently by processing your [(final: prev: { ... }) ... ]
into a single overlay:
{
overlay = final: prev:
lib.composeManyExtensions (import ./my-list-of-overlays.nix);
}
But it still strikes me as odd that there's no ready way of exposing a list of overlays.
I don’t think that allowing a list of overlays is a really good idea as it makes things more painful for the consumer of the flake for no real benefit − either the list is just one big overlay, and it might as well be exported as such, or it’s a set of independent overlays, and it’d better be exported as an attribute set.
Describe the bug
You cannot define the
overlays
output of a flake to be a list, it must be a set. This is despite the documentation stating that it can be a list or set.Steps To Reproduce
Write a flake
nix flake check
Expected behavior
For the check to pass
nix-env --version
output