Split out a package interface for non-single-drv packages

[roberth]

Packages that aren't a single derivation are experimental, but enable new use cases.

• https://github.com/NixOS/rfcs/pull/92
• multi-derivation packages, combining outputs of more than one derivation
  • Example: eliminate doc dependencies when docs aren't used
  • Example: don't rebuild program when doc tooling updates
  • https://github.com/NixOS/nix/issues/6507

[DavHau]

I'm currently browsing through the open issues trying to make a list of tasks to complete on drv-parts before starting to implement dream2nix: v1 API.

My main question here is: Can we make a multi-drv package interface that is useful to end users without having to change nix?

If I implement the multi-drv interface proposed in the linked nix issue, how would we make this compatible to the current nix which expects drvPath?

[roberth]

Can we make a multi-drv package interface that is useful to end users without having to change nix?

The linked issue is in part doubling down on the string context, which is already how expressions work in the language. drvPath is conceptually redundant because it's already part of the output strings contexts. Only the CLI boundary uses this shortcut and bad assumption.

Functions like lib.getBin and pkgs.buildEnv already work with output strings (always have, afaik), so users of expression-based systems like NixOS should not encounter any problems with such packages.

how would we make this compatible to the current nix which expects drvPath?

I suppose you could put a derivation that builds a link farm in drvPath. This way at least all the package outputs will continue to exist when queried as a single derivation. This behavior may still lead to surprises, so maybe there's a case to be made for pkg?drvPath == false, or drvPath = throw "This package consists of multiple outputs that are built by distinct derivations. It can't be understood as a single derivation. It's a package deal.";. Or maybe cut the end off that ;)