-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
nix flake check breaks on IFD in multi-platform flake #4265
Comments
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. |
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 |
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 Or maybe a flag to |
this problem also applies to |
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? |
remove hm build completely Checks fail cross platform due to NixOS/nix#4265
just for reference the iohk cardano-node flake also exhibits the same 'problem/issue/feature'.
|
Here we strip out all other flake dependencies and use similar functions to edolstra/dwarffs and numtide/flake-utils to build a custom flake output that takes system into account. It appears from my bug hunting that the 'nix flake check' failure was introduced with '{ path = "metadata"; }', which uses `builtins.hashFile` on a built derivation, which, if I understand it correctly, is recursive Nix. That appears to mess with the system that builtins.hashFile needs somehow, so the builder for aarch64-linux fails.
This issue has been mentioned on NixOS Discourse. There might be relevant details there: |
How can you know that the machine you're running on is |
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. |
Thanks I see the same error with Nix 2.16
I see that repo uses Perhaps there are two overlapping issues here both causing |
@DavHau , thanks for providing this example With Nix 2.16, the result is:
and
So this is good news. |
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 |
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. |
The problem was expected to be resolved in version 2.16, but it persists in version 2.19.1. The issue occurs specifically during |
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. |
Using a pkgs.writeText causes an import at evaluation time instead of just build time. This means that no host running `nix flake check` can't check all configurations if you have mixed architectures in a flake. For some reason I've been getting away with this. This stopped when switching to nixos-2311. Move the known hosts with a single key into the NixOS config directly and put the GitHub keys in a real file. These can't go into `.knownHosts` directly as it only supports one key per host (sigh). Reference: NixOS/nix#4265
Using a pkgs.writeText causes an import at evaluation time instead of just build time. This means that no host running `nix flake check` can't check all configurations if you have mixed architectures in a flake. For some reason I've been getting away with this. This stopped when switching to nixos-2311. Move the known hosts with a single key into the NixOS config directly and put the GitHub keys in a real file. These can't go into `.knownHosts` directly as it only supports one key per host (sigh). Reference: NixOS/nix#4265
Using a pkgs.writeText causes an import at evaluation time instead of just build time. This means that no host running `nix flake check` can't check all configurations if you have mixed architectures in a flake. For some reason I've been getting away with this. This stopped when switching to nixos-2311. Move the known hosts with a single key into the NixOS config directly and put the GitHub keys in a real file. These can't go into `.knownHosts` directly as it only supports one key per host (sigh). Reference: NixOS/nix#4265
Using a pkgs.writeText causes an import at evaluation time instead of just build time. This means that no host running `nix flake check` can check all configurations if you have mixed architectures in a flake. For some reason I've been getting away with this. This stopped when switching to nixos-2311. Move the known hosts with a single key into the NixOS config directly and put the GitHub keys in a real file. These can't go into `.knownHosts` directly as it only supports one key per host (sigh). Reference: NixOS/nix#4265
I recently added a flake for nixos-appstream-data. This allows us to depend on that flake instead of doing an IFD to load its default.nix. An IFD in nix-software-center is problematic for users who use flakes and have multiple nixos configurations with different architectures. Because of NixOS/nix#4265 this causes `nix flake check` to fail for them.
Exposing nixos-appstream-data as a flake will allow nix-software-center to depend on it the flake way, instead of via an IFD. Having nix-software-center use an IFD is problematic because users of that package may run into NixOS/nix#4265 Adding this flake does not cause an API change for non-flake users.
Exposing nixos-appstream-data as a flake will allow nix-software-center to depend on it the flake way, instead of via an IFD. Having nix-software-center use an IFD is problematic because users of that package may run into NixOS/nix#4265 Adding this flake does not cause an API change for non-flake users.
I recently added a flake for nixos-appstream-data. This allows us to depend on that flake instead of doing an IFD to load its default.nix. An IFD in nix-software-center is problematic for users who use flakes and have multiple nixos configurations with different architectures. Because of NixOS/nix#4265 this causes `nix flake check` to fail for them. Note that users of nix-software-center that do not rely on the flake will still need an IFD. I'm not aware of a better way (other than upstreaming both in nixpkgs).
I recently added a flake for nixos-appstream-data. This allows us to depend on that flake instead of doing an IFD to load its default.nix. An IFD in nix-software-center is problematic for users who use flakes and have multiple nixos configurations with different architectures. Because of NixOS/nix#4265 this causes `nix flake check` to fail for them. Note that users of nix-software-center that do not rely on the flake will still need an IFD. I'm not aware of a better way (other than upstreaming both in nixpkgs).
I recently added a flake for nixos-appstream-data. This allows us to depend on that flake instead of doing an IFD to load its default.nix. An IFD in nix-software-center is problematic for users who use flakes and have multiple nixos configurations with different architectures. Because of NixOS/nix#4265 this causes `nix flake check` to fail for them. Note that users of nix-software-center that do not rely on the flake will still need an IFD. I'm not aware of a better way (other than upstreaming both in nixpkgs). TODO: point this back to snowfallorg's repo after snowfallorg/nixos-appstream-data#1 is merged.
I recently added a flake for nixos-appstream-data. This allows us to depend on that flake instead of doing an IFD to load its default.nix. An IFD in nix-software-center is problematic for users who use flakes and have multiple nixos configurations with different architectures. Because of NixOS/nix#4265 this causes `nix flake check` to fail for them. Note that users of nix-software-center that do not rely on the flake will still need an IFD. I'm not aware of a better way (other than upstreaming both in nixpkgs). Ref: snowfallorg/nixos-appstream-data#1
Before this commit, we use cranelib.cleanCargoSource[1] to filter files in the ./rust/uefi directory. This prevents some rebuilds when files that do not contribute to the build are changed (e.g. a README). However, this causes lanzaboote's flake.nix to contain an IFD[2]. This seems to be unavoidable when using cleanCargoSource[3]. Why this is useful anyway: Since `nix flake check` must check all outputs of the given flake, it's not possible to split a flake check across multiple builder machines. This means that `nix flake check` without `--no-build` can only work if the builder machine has support to build for all architectures present in that flake's `nixosConfigurations` output. This is achievable with binfmt emulation, but excruciatingly slow, especially for use-cases like "run nix flake check in CI". In practice this means that a flake containing nixosConfiguration outputs with different `system` attributes can generally only be `nix flake check`'d with `--no-build`. See [4] for a long discussion on this. Unfortunately, this affects flakes using Lanzaboote transitively. So any flake containing Lanzaboote-enabled nixosConfigurations (like mine[5]) are not be able to use `nix flake check --no-build`. This commit corrects this by removing the IFD. This can be tested with: $ nix store gc # to ensure IFD paths are not cached $ nix flake check --no-build github:nix-community/lanzaboote # fails $ nix store gc $ nix flake check --no-build github:korfuri/lanzaboote # succeeds [1] https://crane.dev/API.html#cranelibfiltercargosources [2] https://nix.dev/manual/nix/2.22/language/import-from-derivation [3] ipetkov/crane#612 [4] NixOS/nix#4265 [5] https://gitlab.com/korfuri/infra/-/blob/77635232eb65e877d8b79eb98f6264381231c20c/flake.nix
This fixes an issue where previously the derivation had to be evaluated before importing the base16 scheme, thus causing `nix flake check` to fail when multi-platform support was added. See: NixOS/nix#4265
My current workaround for this is to use the https://github.com/nix-systems/nix-systems pattern in the flake and then run nix flake show --override-input systems github:nix-systems/aarch64-darwin |
Describe the bug
Given the following flake
nix flake check
will fail withbecause 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.The text was updated successfully, but these errors were encountered: