nix flake: add aarch64-linux as supported platform

[ceedubs]

As of a little while ago, ARM linux builds of ucm are available. This updates the flake to support building them as well, which will enable ceedubs/unison-nix#140 .

[sellout]

Can you also add ubuntu-24.04-arm to the build matrix in .github/workflows/nix-dev-cache.yaml?

It would be great to run that workflow, too, but I’m not sure if it’s possible on a fork (https://github.com/ceedubs/unison/actions/workflows/nix-dev-cache.yaml) … but maybe that can be fixed?

[ceedubs]

I don't think that I can run it off my fork, but I think that I have permission to push to a branch in this repo and trigger an action run from it. I'll give that a try.

[sellout]

https://github.com/unisonweb/unison/actions/runs/16007519475/job/45200631280

Of course, it failed building GHC … in this situation, I usually do a local build and push to the cache so that GitHub doesn’t have to ever build the big things, only Unison. However, I don’t think I have an aarch64-linux box to build on 🤔

[ceedubs]

My only ARM64 machine is a raspberry pi that I don't think could make it through, especially if the GitHub runner is timing out after 60 minutes. I tried running it a few more times in hopes that some incremental results would help, but that doesn't seem to be the case.

I'm not really sure where to go from here. It seems silly for the ucm derivation that just wraps the precompiled binary to be gated because of this. Though admittedly I don't entirely understand why https://github.com/ceedubs/unison-nix/actions/runs/15983063292/job/45081642957?pr=140 failed (or didn't fail before), so maybe I am misdiagnosing the issue.

[sellout]

My only ARM64 machine is a raspberry pi that I don't think could make it through, especially if the GitHub runner is timing out after 60 minutes. I tried running it a few more times in hopes that some incremental results would help, but that doesn't seem to be the case.

Yeah, I don’t think we’ll get anything incremental here – the CI job only pushes to the cache once the build is complete (that might be something we can improve, though).

It seems silly for the ucm derivation that just wraps the precompiled binary to be gated because of this. Though admittedly I don't entirely understand why https://github.com/ceedubs/unison-nix/actions/runs/15983063292/job/45081642957?pr=140 failed (or didn't fail before), so maybe I am misdiagnosing the issue.

That derivation is the source one, the one for the release binary is ucm-bin. You could conditionalize the ucm derivation like

    {
      ucm-bin = pkgs.callPackage ./nix/ucm.nix {inherit darwin-security-hack;};
      # ...
    }
    ## TODO: Unison doesn’t yet support aarch64-linux in its flake (see unisonweb/unison#????)
    // if pkgs.system == "aarch64-linux"
      then {}
      else {ucm = unison.packages.${pkgs.system}.default;};

but I think just adding the system and leaving CI out of it for now (with an issue) is fine.

Another option is that #5486 adopts the nix-systems pattern, which would allow unison-nix to add aarch64-linux downstream, without this repo having to be modified (… after the modification to add nix-systems support).

[ceedubs]

Thanks @sellout! For now I've disabled the CI build of the dev cache for aarch64-linux to move things along. I figure having this there doesn't hurt anything; having a cached version is just a bonus. But I'm also open to the other suggestions.

[sellout]

Sorry, forgot to approve this after you addressed (and then had to revert) my suggestion.