nix.dev icon indicating copy to clipboard operation
nix.dev copied to clipboard

Snippet: how to mix two nixpkgs

Open domenkozar opened this issue 3 years ago • 10 comments

A good example is mixing aarch64-darwin and x86_64-darwin. Another one is using unstable and stable to get different versions of software.

domenkozar avatar Sep 07 '21 07:09 domenkozar

FWIW, I use the following:

❯ cat ~/.config/nixpkgs/overlays/m1.nix
self: super:
let
  pkgs_x86_64 = import <nixpkgs> { localSystem = "x86_64-darwin"; overlays = []; };
in
{
  neovim-unwrapped = pkgs_x86_64.neovim-unwrapped;
  dhall = pkgs_x86_64.dhall;
  elmPackages.elm = pkgs_x86_64.elmPackages.elm;
  packer = pkgs_x86_64.packer;
  ansible = pkgs_x86_64.ansible;
  ansible-lint = pkgs_x86_64.ansible-lint;
}

pecigonzalo avatar Sep 07 '21 13:09 pecigonzalo

@pecigonzalo Did you need to configure anything else in /etc/nix/nix.conf or elsewhere to get x86_64-darwin builds working?

I'm getting this error when trying to build x86-64 packages:

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

I tried adding extra-platforms = x86_64-darwin to /etc/nix/nix.conf but it doesn't seem to have any effect. Do I need to add ssh://localhost as a builder or something?

evanrelf avatar Oct 26 '21 21:10 evanrelf

My nix.conf has this

system = aarch64-darwin
extra-platforms = aarch64-darwin x86_64-darwin

I did not add any special builders or anything

pecigonzalo avatar Oct 27 '21 10:10 pecigonzalo

I figured it out: you have to specify --system x86_64-darwin at the command-line and then it builds fine.

Also I added aarch64-darwin to extra-platforms like you mentioned, for whatever it's worth.

evanrelf avatar Oct 27 '21 16:10 evanrelf

@evanrelf to what command line? Im not passing such argument. Maybe you hav a different workflow?

pecigonzalo avatar Oct 27 '21 16:10 pecigonzalo

Yeah sorry, I wasn't clear. I have a different workflow. I'm nix-building a pkgs.buildEnv derivation, and it was failing on the x86-64 builds until I re-ran the build with the new system.

evanrelf avatar Oct 27 '21 16:10 evanrelf

Does anyone have this as an overlay using only its inputs? I guess it might be impossible, but I'd like to do something roughly like

final : prev : {
  elm = prev.x64_64-darwin.prev;
}

if possible.

kubukoz avatar Dec 01 '21 00:12 kubukoz

@kubukoz You can technically do this:

pkgsFinal: pkgsPrev: {
  x86_64-darwin = import pkgsFinal.path {
    system = "x86_64-darwin";
    inherit (pkgsFinal) config overlays;
  };
}

But it gets tricky very quickly. Using pkgsFinal.overlays in particular is dangerous because it causes stuff like this to infinitely recurse:

pkgsFinal: pkgsPrev: {
  # This is bad!
  hello = pkgsFinal.x86_64-darwin.hello;
}

hello in this overlay is referring to itself because the x86_64-darwin package set is using this overlay!

If you pick a different name, it's okay:

pkgsFinal: pkgsPrev: {
  hello-x86_64 = pkgsFinal.x86_64-darwin.hello;
}

Or if you just use the package in the definition of another:

pkgsFinal: pkgsPrev: {
  env = pkgsPrev.buildEnv {
    name = "my-env";
    paths = with pkgsFinal; [ hello ];
  };
}

evanrelf avatar Dec 01 '21 01:12 evanrelf

@kubukoz For a more concrete/practical example, I do something similar to this in my dotfiles.

  • Here I define the overlay to provide packages for other systems.
  • Here I swap out broken aarch64-darwin packages with x86_64-darwin packages in my Apple silicon laptop config.

evanrelf avatar Dec 01 '21 01:12 evanrelf

That's exactly what I was looking for, I think :) thank you very much. Getting mine in the morning so I'll play around then :joy:

kubukoz avatar Dec 01 '21 01:12 kubukoz