Make building the attribute for a package/project do something sensible

[michaelpj]

At the moment, project.packageSet.foo is an attribute set, containing e.g. components, checks and so on. It also contains things like the package coverage report, various miscellaneous functions, etc.

Similarly, project is an attribute set, containing amongst other things the package set, but also the project coverage report, various miscellaneous functions.

At work, people frequently try and build the package attribute and expect it to, well, build the package, but actually because of how the coverage report is set up, it ends up building the entire project!

Conversely, people often ask "how do I build all the stuff in my project?". At the moment the answer is "use some combination of collectCompnents and collectChecks".

Here's a way we could solve these together:

• Make <package> into an attribute set with recurseForDerivations set.
  • Similarly for components, all the way down to the leaf derivations.
  • (Optional) Also set it for checks?
  • Any derivations currently inside <package> which are not parts of the normal package build (I'm looking at you, coverage report), go into a sub-attribute set without recurseForDerivations set.
  • I think it's fine to keep the functions in there, since they don't interact with building the attribute set.
• Make <project> into an attribute set with recurseForDerivations set.
  • Have a sub-attribute set containing only the project packages, with recurseForDerivations set.
  • Any derivations currently inside <project> which are not parts of the normal project build (coverage report again, but maybe also roots), go into a sub-attribute set without recurseForDerivations set.

The end result of this would be that:

• Building <package> would build all the components of the package (and maybe the tests?), and nothing else.
• Building <project> would build all the components (and maybe the tests?) of the project packages, and nothing else.

I think this would be quite a nice UX.

[rvl]

This is an excellent plan.

About tests, I think checks should be dontRecurseIntoAttrs for starters, to make things simple. Then it would be good to define how test execution will be configured for a project.

It would be wonderful to have package tests run as dependencies of <package>, and all project tests run as dependencies of <project>. It would also be wonderful to have tests suites of dependencies run also, like what is done for the nixpkgs Haskell infra. But unfortunately, tests will often fail without tweaking, due to the nix build environment. There would probably need to be more than one option controlling this.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[michaelpj]

I still think this would be good.