Q: why does flattenTree rely on recurseIntoAttrs?

[mightyiam]

The need to add recurseIntoAttrs causes pollution of the attrset with the marker attribute. That prevents it from being set as the packages output of a flake.

In checks, I do wish to use flattenTree. But in packages I don't. But I must in order to remove the marker attr. And that goes for other places packages ends up in.

This makes me wish for a flattenTree that doesn't need recurseIntoAttrs.

Dime for you thoughts?

[zimbatm]

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.

[jfly]

@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;
};

[zimbatm]

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, ...

[mightyiam]

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.