Fix targetPackages for the purpose of native testing after cross compilation

[roberth]

Describe the bug

Derivation graphs don't require that all are runnable locally, so when you can build derivations on the target, but don't want to because it's slow or expensive, you should still be able to run tests there, using Nix.

Cross compilation is awesome, but it can't (in general) run tests during the build.
That is also ok, because we don't have to run tests in the same derivation that performs the build, and Nix lets us send a test derivation to the right machine based on the derivation system.
We already have the tests attribute for defining such test derivations; normally specified via passthru.tests, but it's currently not really possible to set them up to do this in a clean way that's acceptable for Nixpkgs.

Some context

Derivations are built on machines that support the derivation system in their Nix options (also called system, or extra-platforms).
Nixpkgs always defines the derivation system as buildPlatform.system, as it must. So far so good.

In cross compilation from a given build platform b to a host platform h, we have the following package sets:

• buildPackages, where buildPlatform is b and hostPlatform is also b
• the "current" package set, aliased as pkgs, where buildPlatform is b, but hostPlatform is h
• targetPackages, where buildPlatform and hostPlatform are both h

Normally we don't have to think much about target for various reasons, but primarily the fact that most of the time we aren't configuring a compiler that hardcodes this choice into its configuration.

The thing is though, targetPackages is completely broken in a cross-configured Nixpkgs.

nix-repl> attrNames targetPackages
[
  "__raw"
  "recurseForDerivations"
  "stdenv"
]

This isn't a Nixpkgs package set at all, and that's a problem.

• So while targetPackages would let us produce these test derivations, it doesn't work.

Steps To Reproduce

nix repl -f . --argstr system x86_64-linux --argstr crossSystem aarch64-darwin
nix-repl> :b hello.tests.run

Expected behavior

The above command sends a derivation to an aarch64-darwin builder and succeeds.

Screenshots

Additional context

Alternatively, a VM could be set up inside a derivation that runs on buildPlatform. This would preclude testing on real hardware.

Splicing won't be necessary for making this work, as finalAttrs.finalPackage has the right hostPlatform to run in a targetPackages derivation.

As mentioned, target may be thought of as "the thing we don't need and shouldn't need", and maybe that's why it's intentionally broken in cross? I don't think that makes 100% sense because it does "work" on non-cross pkgs. If it were intentional, surely we'd want to break it there too.
Nonetheless, if a different name is needed then that's probably fine. testPackages might feel intuitive.

Testing using targetPackages may look like

{ targetPackages, stdenv, ... }:

stdenv.mkDerivation (finalAttrs: {
  # ...
  passthru.tests.run = targetPackages.callPackage ./tests/run.nix { foo = finalAttrs.finalPackage; };
})

Maybe targetPackages.callPackage could be aliased to callTest.

Alternatively, perhaps testers should imply a switch to targetPackages?

Implementing both would cause a switch to targetPackages.targetPackages, which is bad conceptually, but easy to work around by defining targetPackages.targetPackages to refer to targetPackages (just as pkgs.pkgs is (more rightfully) identical to pkgs).

Notify maintainers

Metadata

Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.

[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
output here

---

Add a 👍 reaction to issues you find important.