haskellPackages.mkDerivation: passthru attributes for executables, testExecutables and benchExecutables

[mrcjkb]

Hey 👋

I've recently migrated a project from haskell.nix to nixpkgs/cabal2nix.
One thing I found quite useful in haskell.nix was the ability to directly reference executables, test executables and benchmark executables, e.g.:

Cabal:

executable my-package-foo
  main-is: MyPackageFoo.hs

executable my-package-bar
  main-is: MyPackageBar.hs

my-package-foo = my-package.exes.my-package-foo
my-package-bar = my-package.exes.my-package-bar

I had a look at fromPackageDescription, as well as the Pretty instance of Derivation,
and I think it wouldn't be too hard to generate something like this:

mkDerivation {
  # ...
  passthru = {
    executables = {
      my-package-foo = haskell.lib.compose.setBuildTarget "my-package-foo" my-package;
      my-package-bar = haskell.lib.compose.setBuildTarget "my-package-foo" my-package;
    };
    testExecutables = {
      my-package-foo-spec = haskell.lib.compose.setBuildTarget "my-package-foo-spec" my-package;
      my-package-bar-integration = haskell.lib.compose.setBuildTarget "my-package-bar-intergration" my-package;
    };
    benchExecutables = # ...
  };
}

What do you think?
Am I missing something? Would you consider this a useful feature?

An obvious downside would be the need for my-package to be passed in via callPackage.
This could be mitigated by providing executable names instead of derivations.

[sternenseemann]

The implementation could likely mostly live in nixpkgs with something equivalent as NixOS/cabal2nix#617 being implemented for cabal2nix to list out executable targets. As you can see from the discussion on that PR, there are some reservations about generating this additional metadata, though, mainly code size.

I don't think having individual derivations for the components as you propose would be a good idea, since nixpkgs doesn't have component-level granular derivations, but has one big one for everything. Making tons of variants of the same derivation would cause a lot of needless rebuilds of the same stuff potentially since we can't share the work between derivations. I don't think the idea you propose is as useful if you want to use .exes.foo and .exes.bar which both depend on the same internal lib, but that library has to be built twice.

(Maybe not the 100% most accurate thing to transfer the issue since it does need some groundwork in cabal2nix, but clicked too fast…)

[mrcjkb]

That's a fair point about individual derivations for components.

I suppose the only option to address code size concerns for this feature would be to put it behind a CLI flag.