Open mightyiam opened 8 months ago
If packages
is an attrs of derivations, it doesn't need flattenTree
as the tree is already flat.
If it has a hierarchy, it's incompatible with the packages
schema since it only allows derivations as values. In that case, the package set has to be put in legacyPackages
to conform with the flake schema, and having an additional recurseIntoAttrs doesn't matter.
@zimbatm, how about specifically for checks? Here's a snippet from our flake.nix:
checks = flake-utils.lib.flattenTree {
packages = (recurseIntoAttrs packages);
nixosTests = (recurseIntoAttrs nixosTests);
};
(where there is some collision in the keys between packages
and nixosTests
, so we use flattenTree
to ensure uniqueness in the final checks
attrset)
The above code works, but it is bit cumbersome to have to call recurseIntoAttrs
on every value. We'd prefer to write this as:
checks = flake-utils.lib.flattenTree {
inherit packages nixosTests;
};
It would make sense to add a flake-utils.lib.mkChecks
for that. There might be also a smart variant flake-utils.lib.mkDefaultChecks self system
that automatically picks the packages, nixosTests, ...
I like the mkDefaultChecks
idea. It would take only self, I suppose? I can see it also making a formatting check from the formatter output.
I'm not sure, in that case, of the value of mkChecks.
The need to add
recurseIntoAttrs
causes pollution of the attrset with the marker attribute. That prevents it from being set as thepackages
output of a flake.In
checks
, I do wish to use flattenTree. But inpackages
I don't. But I must in order to remove the marker attr. And that goes for other placespackages
ends up in.This makes me wish for a
flattenTree
that doesn't needrecurseIntoAttrs
.Dime for you thoughts?