nix flake check breaks on IFD in multi-platform flake

[Kha]

Describe the bug

Given the following flake

{
  description = "A very basic flake";

  inputs.flake-utils.url = github:numtide/flake-utils;

  outputs = { self, nixpkgs, flake-utils }: flake-utils.lib.eachDefaultSystem (system:
    with nixpkgs.legacyPackages.${system}; {
      checks.hello = import (writeText "hi" "hi");
    });
}

nix flake check will fail with

error: --- Error --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- nix
a 'aarch64-linux' with features {} is required to build '/nix/store/xqdq3nrw9s3f7vpn1zzsryhsqkh23634-hi.drv', but I am a 'x86_64-linux' with features {benchmark, big-parallel, kvm, nixos-test}
(use '--show-trace' to show detailed location information)

because while it does not build checks of foreign platforms, it still tries to evaluate them, which with IFDs can lead to building after all.

Expected behavior

nix flake check should catch uses of IFD and perhaps print a warning but continue to check other parts. Alternatively, there could be a check attribute or cmdline flag that disable evaluation on foreign platforms.

[matthewbauer]

A hacky workaround is just to use nixpkgs.legacyPackages.x86_64-linux for evaluation and nixpkgs.legacyPackages.${system} for the actual derivation. Usually you're just doing some preprocessing so it works out to evaluate on one system and build on another.

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/how-to-use-flakes-with-ifd/10300/2

[nrdxp]

FWIW, we have actually be using this "bug" to detect surprising or unwanted IFD in devos. Maybe, after fixing this we could make some sort of library or builtin function, such as isIFD, in order to continue detecting it in unwanted places 😄

Or maybe a flag to nix flake check such as --fail-on-ifd that preserves the current behavior.

[colonelpanic8]

this problem also applies to nix flake show

[colonelpanic8]

Hmmm. It seems like IFD definitely needs to be allowed in e.g. defaultPackages. Does anyone have any ideas about what the right solution here is?

[nixinator]

just for reference the iohk cardano-node flake also exhibits the same 'problem/issue/feature'.

nix flake show github:input-output-hk/cardano-node

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/nix-flake-show-fails-when-the-flake-provides-packages-for-other-platforms/18726/2

[yajo]

A hacky workaround is just to use nixpkgs.legacyPackages.x86_64-linux for evaluation and nixpkgs.legacyPackages.${system} for the actual derivation.

How can you know that the machine you're running on is x86_64-linux? Maybe you're on an aarch64-linux and evaluating a derivation for x86_64-linux.

[anka-213]

I wish there was a way to say that an IFD is platform independent (probably necessitating a hash of the expected resulting nix expression). That way you could handle other platforms while still evaluating on the local platform. It could probably work somewhat similarly to other fixed output derivations like file downloads.

[jamesdbrock]

It seems like using nixConfig might work around this issue:

  nixConfig = {
    allow-import-from-derivation = "true"; # TODO doesn't work? 
  };

#4189

I see this done for example here:

https://github.com/hasktorch/hasktorch/blob/7b63d730964a44a6bcdd853cd5b140a24e210298/flake.nix#L16

but my nix flake show still fails with

error: cannot build '/nix/store/h91k9g6ppgwncazpli9rz82y1xl0w9zj-source.drv' during evaluation because the option 'allow-import-from-derivation' is disabled

[peterbecich]

Thanks

I see the same error with Nix 2.16

$  nix flake check github:hasktorch/hasktorch   
...
error: a 'x86_64-darwin' with features {} is required to build
'/nix/store/h3prp5ng7ghxcv9xcyf0bdkrjnvclilr-alex-3.2.4-r1-src.drv',
but I am a 'x86_64-linux' with features

I see that repo uses haskell.nix. I have raised the same issue there: input-output-hk/haskell.nix#1825

Perhaps there are two overlapping issues here both causing nix flake check to fail; something with IFD in nix itself, and something specifically in haskell.nix.

[peterbecich]

@DavHau , thanks for providing this example
#4265 (comment)

With Nix 2.16, the result is:

$  nix flake check
warning: The check omitted these incompatible systems: aarch64-darwin, aarch64-linux, x86_64-darwin
Use '--all-systems' to check all.

and

 $ nix flake check --all-systems
error:
       … while checking flake output 'checks'

         at /nix/store/dbppismymjc6382g4v6d6sb99pjby37b-source/lib.nix:73:15:
....

       error: a 'aarch64-darwin' with features {} is required to build 
'/nix/store/fqbrhssl2h3064277p8a9yjz8m4qsskc-hi.nix.drv', 
but I am a 'x86_64-linux' with features {benchmark, big-parallel, kvm, nixos-test, uid-range}

So this is good news.

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/help-understanding-templates-haskell-nix/30990/1

[zmrocze]

I remember this issue since forever. Can we add a simple flag filtering outputs for just one system? As simple partial workaround, like:

$ nix flake show --system=x86_64-linux
├───checks
│   └───x86_64-linux
│       ├───"homeConfiguraton_zmrocze@omen": derivation 'home-manager-generation'
│       └───pre-commit: derivation 'pre-commit-run'
├───devShells
│   └───x86_64-linux
│       ├───default: development environment 'nix-shell'
├───homeConfigurations: unknown
└───nixosConfigurations
    ├───omen: NixOS configuration

This is still helpful for local development, i.e. when I'm including all outputs from some dynamically defined flake and I don't know the attribute names.

[klarkc]

The problem was expected to be resolved in version 2.16, but it persists in version 2.19.1. The issue occurs specifically during nix flake check in haskell.nix. I don't know what steps to take to address this. My current approach involves removing support for all other systems and any form of cross-compilation.

[Dessix]

Wasn't the whole point of flakes to make cross-system management viable because Hydra couldn't manage the prior system? Removing it seems like giving up one of the primary motivators that led to inconvenience in almost every other area of functionality.