blueprint icon indicating copy to clipboard operation
blueprint copied to clipboard

support multiple instances of nixpkgs

Open zimbatm opened this issue 1 year ago • 7 comments

At the moment, only the "nixpkgs" input is used to:

  • instantiate nixos instances.
  • configure the pkgs argument.

Some users might want to use different versions of nixpkgs for different machines (eg: stable and unstable)

zimbatm avatar Jul 02 '24 05:07 zimbatm

or, use multiple nixpkgs? For instance, I like my OS nixpkgs to be pinned to the current nixos-release tag, but use certain applications from the unstable, or even trunk...

kriswill avatar Jul 07 '24 04:07 kriswill

The current workaround is to create a modules/common/nixpkgs-unstable.nix module.

{ inputs, pkgs, .... }:
{
  _module.args.pkgsUnstable = import inputs.nixpkgs-unstable {
    inherit (pkgs) system;
    config.allowUnfree = true;
  };
}

Then import it in whatever module needs it:

{ flake, pkgsUnstable, ... }:
{
  # Import to add the pkgsUnstable argument
  imports = [ flake.modules.common.nixpkgs-unstable ];
  # Pull the package from pkgsUnstable
  services.myservice.package = pkgsUnstable.myservice;
}

zimbatm avatar Jul 07 '24 18:07 zimbatm

Do you have a plan for the "api" you'd like to expose here, @zimbatm? In other words, how would people specify which instance of nixpkgs to use for each host?

I personally like being able to patch nixpkgs (example here) before using it to define my nixosConfigurations. It would be quite cool if whatever API we design here would allow for something like that.

I'd be interested in trying to implement this if you're open to a PR.

jfly avatar Sep 13 '24 03:09 jfly

Not super precisely.

There is a need for patching/overriding inputs. For this, we could add inputs/<name>/default.nix pattern that can be used to override said inputs. Details tbd.

Then, there is a need to map a nixpkgs input to a host. We have hosts/<hostname>/default.nix where you can do your own calls to nixosSystem, but then it's missing some of the integration / specialArgs that blueprint is providing. Ideally you could just map a specific host to a specific nixpkgs input. Maybe introduce a hosts/inventory.toml or hosts/<hostname>/meta.toml where the mapping could be specified. This would also open the road to adding other meta information like the SSH users for deploy tools.

zimbatm avatar Sep 13 '24 09:09 zimbatm

you could also just do

nixpkgs.overlays = [
  (final: _prev: {
    unstable = import nixpkgs-unstable {
      inherit (final) system config;
    };
  })
];

this way pkgs.unstable.* will reference to the unstable channnel's package, you could also use legacyPackages but idk if it will take over the parent nixpkgs config...

JumpIn-Git avatar Jan 18 '25 09:01 JumpIn-Git

Since then we also added the perSystem module argument that filters the flake input packages by the target system.

Eg:

{ perSystem, ... }:
{
  nix.package = perSystem.nixpkgs-unstable.nix;
}

zimbatm avatar Jan 18 '25 09:01 zimbatm

Since then we also added the perSystem module argument that filters the flake input packages by the target system.

Eg:

{ perSystem, ... }: { nix.package = perSystem.nixpkgs-unstable.nix; }

wow didnt think of that the perSystem function is so usefull

JumpIn-Git avatar Jan 18 '25 09:01 JumpIn-Git

There is a need for patching/overriding inputs. For this, we could add inputs/<name>/default.nix pattern that can be used to override said inputs. Details tbd.

I was looking for this functionality to use applyPatches. I think it would be great to have the equivalent of this as a standalone feature for patching any input. On first this is independent of the type of input so it could be used beyond nixpkgs inputs.

steveej avatar Dec 08 '25 10:12 steveej

(shameless self promotion)

@steveej, check out https://github.com/jfly/flake-input-patcher. It lets you patch any input, and you can still use blueprint (or whatever flake framework you want).

jfly avatar Dec 08 '25 15:12 jfly