Skip to content
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

support multiple instances of nixpkgs #22

Open
zimbatm opened this issue Jul 2, 2024 · 4 comments
Open

support multiple instances of nixpkgs #22

zimbatm opened this issue Jul 2, 2024 · 4 comments
Labels
enhancement New feature or request

Comments

@zimbatm
Copy link
Member

zimbatm commented Jul 2, 2024

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 zimbatm added the enhancement New feature or request label Jul 2, 2024
@kriswill
Copy link

kriswill commented Jul 7, 2024

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...

@zimbatm
Copy link
Member Author

zimbatm commented Jul 7, 2024

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;
}

@jfly
Copy link

jfly commented Sep 13, 2024

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.

@zimbatm
Copy link
Member Author

zimbatm commented Sep 13, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants