Can't eval aarch64-linux package on x86_64-linux

[colemickens]

Since adding helix's flake to my nixcfg, I'm no longer able to evaluate my aarch64 systems on my x86_64 boxes. This is pretty painful since I rely on evaluating on my main CI machine and then remote building the derivations and copying outputs back.

I'm not sure though, if this is because of a specific Rust dep that is triggering this, or if its an overall symptom of helix's use of nix-cargo-integration.

Any tips?

❯ nix eval --raw --derivation 'github:helix-editor/helix/e267dc#packages.aarch64-linux.helix'
error: a 'aarch64-linux' with features {} is required to build '/nix/store/l4r33m9ys148295f3djjys1hf1vxpvap-crates-io-aho-corasick-0.7.18.drv', but I am a 'x86_64-linux' with features {benchmark, big-parallel, kvm, nixos-test, recursive-nix}
(use '--show-trace' to show detailed location information)

[yusdacra]

This is probably because crate2nix uses IFD, at least that's what I think since this happens in eval. I've been trying to switch to using dream2nix only, which has a no-IFD buildRustPackage builder (and soon a crane builder) so it should work much better. There is no granular builder yet (like crate2nix) however so it sadly would be worse for caching (thought the crane builder will remedy this since it can build dependencies separately like naersk).

[yusdacra]

It would be appreciated if you could try #56 on helix's flake, and in your configuration. It should hopefully "just work".

[colemickens]

I can't dig in a ton right now, so I may have made a mistake, but I tried this naively:

    helix.url = "github:helix-editor/helix";
    #helix.inputs.nixpkgs.follows = "nixpkgs";
    nci.url = "github:yusdacra/nix-cargo-integration/feed2c1f7ae104f38c295c210f3a26088ed3cf4f";
    helix.inputs.nixCargoIntegration.follows = "nci";

and got:

error: 'makeOutputs' at /nix/store/dc3gxpiynqd74n2bnka9a3377k81w4s7-source/src/lib.nix:17
9:5 called with unexpected argument 'buildPlatform'

       at /nix/store/csrphcmp29rvd8lnb7ymkaj1313yha41-source/flake.nix:15:5:

           14|   outputs = inputs@{ self, nixCargoIntegration, ... }:
           15|     nixCargoIntegration.lib.makeOutputs {
             |     ^
           16|       root = ./.;
(use '--show-trace' to show detailed location information)

[yusdacra]

If you remove the buildPlatform attribute, it should try to run at least. That was removed in that PR, since it just uses dream2nix now.

[colemickens]

I've just forked for now, to minimize any weird flake stuff going on:
colemickens/helix@f4a4960

But when I eval one of my toplevels, I get error: stack overflow (possible infinite recursion)

Just to check, this is still what I'm using to pull in helix: inputs.helix.outputs.packages.${pkgs.system}.helix

[colemickens]

I've bumped to "github:yusdacra/nix-cargo-integration/5c4e36760a232feb572fb5f9b46e8d262dbec42e" and same result.

[yusdacra]

I've just forked for now, to minimize any weird flake stuff going on:
colemickens/helix@f4a4960

But when I eval one of my toplevels, I get error: stack overflow (possible infinite recursion)

Just to check, this is still what I'm using to pull in helix: inputs.helix.outputs.packages.${pkgs.system}.helix

Ugh, infinite recursion errors, that is really annoying. I'll take a look at it soon and try to fix it.

[colemickens]

It seems like the issue has to do with either how helix is loading source via ./. or nix-cargo-integration or both. Changing root = ./. to a convoluted call to filterSource got me an error further in.

If you pull the helix commit from my fork you can just build the pkg output directly to get the more useful error. I'm not really sure why it manifests as a stack overflow when its used as part of my system.

[yusdacra]

I also get a stack overflow error, on your fork. I'm not really sure where this could happen, since there are so many layers, but I'll try looking at nix-cargo-integration first since I suspect some of the recent changes cause this, but we'll see...

Note: completely clearing the flake and just using a plain makeOutputs still gives a stack overflow, so it's not the overrides I believe.

[yusdacra]

I can reproduce the stack overflow with a simple dream2nix flake on helix, so it looks like the bug is in dream2nix most likely, with my builder implementation (or perhaps translator).

The problem seems to happen with a main branch of dream2nix, and with any builder of rust. The translator works fine as I tested it separately, so I believe this issue lies in the vendoring.

I made an issue on dream2nix here nix-community/dream2nix#86.

[colemickens]

Thanks for the update and the time you're investing in this area, I'm excited to switch some other Rust stuff to it.

[yusdacra]

I've spent the last 2 weeks working on improving Rust builders over on dream2nix and I think I can now say they actually work pretty well! I have got helix to build using this flake:

{
  description = "A post-modern text editor.";

  inputs = {
    nixpkgs.url = "github:nixos/nixpkgs/nixos-unstable";
    rust-overlay.url = "github:oxalica/rust-overlay";
    nixCargoIntegration = {
      url = "github:yusdacra/nix-cargo-integration/dream2nix-only";
      inputs.nixpkgs.follows = "nixpkgs";
      inputs.rustOverlay.follows = "rust-overlay";
    };
    helix = {
      url = "https://github.com/helix-editor/helix.git";
      type = "git";
      submodules = true;
      flake = false;
    };
  };

  outputs =
    inputs @ {
      nixCargoIntegration,
      helix,
      ...
    }:
      nixCargoIntegration.lib.makeOutputs {
        root = ./.;
        renameOutputs = { "helix-term" = "helix"; };
        # Set default app to hx (binary is from helix-term release build)
        # Set default package to helix-term release build
        defaultOutputs = {
          app = "hx";
          package = "helix";
        };
        overrides = {
          crateOverrides = common: _: {
            helix-term = prev: {
              buildInputs = (prev.buildInputs or []) ++ [common.cCompiler.cc.lib];
              nativeBuildInputs = (prev.nativeBuildInputs or []) ++ [common.pkgs.makeWrapper];
              preConfigure = ''
                ${prev.preConfigure}
                rm -r helix-syntax/languages
                ln -s ${helix}/helix-syntax/languages helix-syntax/languages
                ln -s "$PWD/helix-syntax/languages" languages
                mkdir -p runtime/grammars
              '';
              postInstall = ''
                ${prev.postInstall}
                mkdir -p $out/lib
                cp -r runtime $out/lib
                wrapProgram "$out/bin/hx" --set HELIX_RUNTIME "$out/lib/runtime"
              '';
            };
          };
        };
      };
}

Note that you will probably need to wait a long time for all the submodules to be fetched, nix doesn't seem to output anything while it's doing that (thought it was stuck a few times, should've used pkgs.fetchFromGitHub...). Hopefully the PR that removes submodules in helix gets merged soon so this no longer needs to be used.

[yusdacra]

Closing this since it is done.