3

If I look at the outputs provided by the haskell.nix flake from a M1 computer, it starts building ghc-8.8.4 etc..

❯ nix flake show github:input-output-hk/haskell.nix
github:input-output-hk/haskell.nix/1b54ea01568299a0eda578ae9395e20d5c699ee1
├───checks
│   ├───aarch64-darwin
trace: haskell-nix.haskellLib.cleanGit: /nix/store/jmx2m0ldgrjq7p3gb4yyca47nvbvspfl-source does not seem to be a git repository,
assuming it is a clean checkout.
trace: No index state specified for haskell-project, using the latest index state that we know about (2022-02-07T00:00:00Z)!
trace: No index state specified for haskell-project, using the latest index state that we know about (2022-02-07T00:00:00Z)!
trace: No index state specified for haskell-project, using the latest index state that we know about (2022-02-07T00:00:00Z)!
trace: WARNING: No materialized dummy-ghc-data for ghc-8.8.4-aarch64-darwin.
trace: To make this a fixed-output derivation but not materialized, set `sha256` to the output of the 'calculateMaterializedSha' script in 'passthru'.
trace: To materialize this entirely, pass a writable path as the `materialized` argument and run the 'updateMaterialized' script in 'passthru'.
[1/0/579 built, 0.1 MiB DL] building ghc-8.8.4 (buildPhase):.....

From an Intel Mac, I get

❯ nix flake show github:input-output-hk/haskell.nix
github:input-output-hk/haskell.nix/1b54ea01568299a0eda578ae9395e20d5c699ee1
├───checks
│   ├───aarch64-darwin
trace: haskell-nix.haskellLib.cleanGit: /nix/store/jmx2m0ldgrjq7p3gb4yyca47nvbvspfl-source does not seem to be a git repository,
assuming it is a clean checkout.
trace: No index state specified for haskell-project, using the latest index state that we know about (2022-02-07T00:00:00Z)!
trace: No index state specified for haskell-project, using the latest index state that we know about (2022-02-07T00:00:00Z)!
trace: No index state specified for haskell-project, using the latest index state that we know about (2022-02-07T00:00:00Z)!
error: --- Error ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- nix
a 'aarch64-darwin' with features {} is required to build '/nix/store/sc11rh4l348yw3z4q4fy4byw324nm5yz-nix-tools-plan-to-nix-pkgs.drv', but I am a 'x86_64-darwin' with features {benchmark, big-parallel, nixos-test, recursive-nix}
(use '--show-trace' to show detailed location information)

Why do those flakes need to build anything for showing their outputs ?

If I run this command on some other flake I have, after a few fetches :

❯ nix flake show github:edolstra/dwarffs
github:edolstra/dwarffs/69d73417d83ebeb7711912e33515d87049b39de0
├───checks
│   ├───aarch64-linux
│   │   ├───build: derivation 'dwarffs-0.1.20220128.69d7341'
│   │   └───test: derivation 'vm-test-run-unnamed'
│   ├───i686-linux
│   │   ├───build: derivation 'dwarffs-0.1.20220128.69d7341'
│   │   └───test: derivation 'vm-test-run-unnamed'
│   └───x86_64-linux
│       ├───build: derivation 'dwarffs-0.1.20220128.69d7341'
│       └───test: derivation 'vm-test-run-unnamed'
├───defaultPackage
│   ├───aarch64-linux: package 'dwarffs-0.1.20220128.69d7341'
│   ├───i686-linux: package 'dwarffs-0.1.20220128.69d7341'
│   └───x86_64-linux: package 'dwarffs-0.1.20220128.69d7341'
├───nixosModules
│   └───dwarffs: NixOS module
└───overlay: Nixpkgs overlay
Peter Becich
  • 989
  • 3
  • 14
  • 30
nicolas
  • 9,549
  • 3
  • 39
  • 83

1 Answers1

6

haskell.nix depends heavily on what is commonly called "import from derivation" or IFD. These are expressions such as

foo = import "${mkDerivation bar}/expr.nix";

or

qux = builtins.readFile (somePackage + "/data.json");

These can not be evaluated without building bar and somePackage.

haskell.nix does have a feature that lets you avoid such expressions altogether. They've called it materialization.

Robert Hensing
  • 6,708
  • 18
  • 23
  • now we need monads :)) – nicolas Feb 08 '22 at 14:21
  • what's bothering is that it fails on my platform (macOS both intel and M1) at some point. so I can't even see the content. it would be nice to have a form of lazy evaluation here. – nicolas Feb 08 '22 at 14:23
  • Monads tend to be less inspectable. Indeed IFD can be seen as monadic composition on some model of Nix. – Robert Hensing Feb 09 '22 at 16:23
  • 1
    RFC 92 proposes a mechanism that allows the outputs to be computed lazily. If the other package attributes can be returned without IFD, e.g. by hardcoding, it is part of a solution to your problem. https://github.com/NixOS/rfcs/pull/92 – Robert Hensing Feb 09 '22 at 16:25
  • I was just kidding about monad (or not.. but mostly kidding. monads are not the only way to modularize. Ideally we would have one single language smart enough to adapt to the various usage, inc deployment, and somehow I have doubts Nix is it.). It's amazing how "configuration" is very often orders of magnitude more complex than the "business" logic it is supposed to support. Thank you for the link. This seems important. – nicolas Feb 09 '22 at 18:16