Confusing way of setting nixpkgs options with lib.homeManagerConfiguration [Nix Flakes]

[funketh]

The nixpkgs.config options are overridden here: https://github.com/nix-community/home-manager/blob/5ac84ebeef5d2566ea458b81375cc6eafa19c225/flake.nix#L47-L56 This was very confusing and unintuitive since I did not know about the pkgs parameter (it isn't mentioned in the online documentation) and my nixpkgs.config.allowUnfree = true; in the actual configuration got ignored.

Personally, I would be against overriding these here. (The NixOS equivalent lib.nixosSystem does not do this either afaik.) At the very least the pkgs option (and its relevance for config options such as allowUnfree) should be mentioned in the docs.

[cmm]

see also #2942 FTR I still totally don't get how nixpkgs.config.allowUnfree = true worked before and (subsequently) how exactly did https://github.com/NixOS/nixpkgs/commit/1c49b81263858c69b932da05ae63a7767b308e74 break it

[PaulGrandperrin]

I agree this interface is very confusing, but I would like pkgs to continue to be settable, otherwise home-manager becomes uncomposable. In fact, I think it should be the normal way to set it, and stop using follows in the inputs.

Here's an example of flake.nix:

{
  inputs = {
    nixos-unstable.url = "github:nixos/nixpkgs/nixos-unstable";
    nixos-unstable-small.url = "github:nixos/nixpkgs/nixos-unstable-small";
    nixpkgs-darwin-unstable.url = "github:nixos/nixpkgs/nixpkgs-darwin-unstable";
 
	home-manager.url = "github:nix-community/home-manager";
    home-manager.inputs.nixpkgs.follows = "nixpkgs"; # using this method prevents composition and is confusing
  };

  outputs = inputs:
      homeConfigurations = {
	        aaa = inputs.home-manager.lib.homeManagerConfiguration {
	          pkgs = inputs.nixos-unstable.legacyPackages.x86_64-linux;
			  ...
	        };
		    bbb = inputs.home-manager.lib.homeManagerConfiguration {
	          pkgs = inputs.nixos-unstable-small.legacyPackages.x86_64-linux;
			  ...
	        };
			ccc = inputs.home-manager.lib.homeManagerConfiguration {
	          pkgs = inputs.nixpkgs-darwin-unstable.legacyPackages.x86_64-linux;
			  ...
	        };
		};
    }
}

otherwise, we would have to duplicate home-manager and hard code all of its versions in the inputs:

{
  inputs = {
    nixos-unstable.url = "github:nixos/nixpkgs/nixos-unstable";
    nixos-unstable-small.url = "github:nixos/nixpkgs/nixos-unstable-small";
    nixpkgs-darwin-unstable.url = "github:nixos/nixpkgs/nixpkgs-darwin-unstable";
 
	home-manager.url = "github:nix-community/home-manager";
    home-manager.inputs.nixpkgs.follows = "nixos-unstable";

	home-manager-small.url = "github:nix-community/home-manager";
    home-manager-small.inputs.nixpkgs.follows = "nixos-unstable-small";

	home-manager-darwin.url = "github:nix-community/home-manager";
    home-manager-darwin.inputs.nixpkgs.follows = "nixos-darwin-unstable";
  };

  outputs = inputs:
      homeConfigurations = {
	        aaa = inputs.home-manager.lib.homeManagerConfiguration {
			  ...
	        };
		    bbb = inputs.home-manager-small.lib.homeManagerConfiguration {
			  ...
	        };
			ccc = inputs.home-manager-darwin.lib.homeManagerConfiguration {
			  ...
	        };
		};
    }

[cmm]

FWIW I see nothing particularly wrong with this way of specifying pkgs, or with the fact that it is a parameter. It's the same for NixOS, actually, the default is different but works out to superficially the same thing.

But only superficially -- it seems that lately (at least) Nixpkgs acquired some bug that prevents modular overlays and nixpkgs options from working, at least when you use flakes and the pkgs that is provided to either homeConfigurations or nixosConfigurations is nixpkgs.legacyPackages.${system} or a variation (import nixpkgs { inherit system; } causes same misbehavior).

Basically it seems that something is subtly wrong with some magical Nixpkgs fixpoint. I have no idea how to debug this, alas :(

[LunNova]

In #2720 I wanted to simplify this so it's easier to pass in a pkgs argument that gets used without being re-imported and configured again, but it wasn't really backwards compatible. :/

Currently I use:

        makeUser = username:
          import "${home-manager}/modules" {
            inherit pkgs;
            check = true;
            extraSpecialArgs = {
              # Some extra args specific to my config
              inherit pkgs-stable;
              nixosConfig = null;
              lun = args.self;
            };
            configuration = {
              _module.args.pkgs = lib.mkForce pkgs;
              _module.args.pkgs_i686 = lib.mkForce { };
              imports = [ "${./users}/${username}" ];
              home.homeDirectory = "/home/${username}";
              home.username = "${username}";
            };
          };

and mkForce args.pkgs to be my own pkgs input, instead of letting HM import it again. If #2720 gets merged the same approach can be simplified by passing useNixpkgsModule = false; and dropping the _module.args.pkgs* parts.

[acowley]

EDIT: Sorry for the noise, the workaround was already shared.

I apologize if I'm not interpreting this Issue correctly, but can someone suggest how I should be setting allowUnfree now? I've been using this as the core of a configuration I use on NixOS, Ubuntu, and macOS machines,

homeManager.lib.homeManagerConfiguration {
  configuration = { pkgs, lib, ... }: {
    imports = [ ./common.nix ] ++ extraImports;
    nixpkgs = {
      overlays = ...;
      config = { allowUnfree = true; };
    };
  };
  inherit system homeDirectory;
  username = "acowley";
  stateVersion = "21.11";
}

But allowUnfree is not being set. Where can I set it so that it sticks?

[sandangel]

Just have this issue and overcome by overriding the pkgs instead

  outputs = { self, nixpkgs, nixpkgs-unstable, home-manager, ... }@inputs:
  let
    # define system, username etc...
    pkgs = import nixpkgs-unstable {
      inherit system;
      config.allowUnfree = true;
      config.allowUnsupportedSystem = true;
      overlays = [
        inputs.neovim-nightly-overlay.overlay
      ];
    };
  in {
    homeConfigurations.${username} = home-manager.lib.homeManagerConfiguration {
      inherit system username pkgs;
      configuration = import ./users/${username}/home.nix;
      homeDirectory = "/home/${username}";
      stateVersion = "22.05";
    };
}

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/nixpkgs-unfree-configs-not-respected/20546/7

[stale[bot]]

Thank you for your contribution! I marked this issue as stale due to inactivity. Please be considerate of people watching this issue and receiving notifications before commenting 'I have this issue too'. We welcome additional information that will help resolve this issue. Please read the relevant sections below before commenting.

If you are the original author of the issue

• If this is resolved, please consider closing it so that the maintainers know not to focus on this.
• If this might still be an issue, but you are not interested in promoting its resolution, please consider closing it while encouraging others to take over and reopen an issue if they care enough.
• If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

If you are not the original author of the issue

• If you are also experiencing this issue, please add details of your situation to help with the debugging process.
• If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

Memorandum on closing issues

Don't be afraid to manually close an issue, even if it holds valuable information. Closed issues stay in the system for people to search, read, cross-reference, or even reopen – nothing is lost! Closing obsolete issues is an important way to help maintainers focus their time and effort.

[PaulGrandperrin]

As I described in #4571, pkgs is not actually used directly.

We can use this to our advantage and trick home-manager into honoring nixpkgs.config, nixpkgs.system and nixpkgs.overlays.

It's really neat to be able to set them in a modular way, exactly as in NixOS.

Here's an example:

homeConfigurations.test = inputs.home-manager-master.lib.homeManagerConfiguration {
	pkgs = { # it's fake but it's not this version of `pkgs` that will actually be used
		path = inputs.nixos-unstable; # path or flake to the version of `nixpkgs.pkgs` you want
		lib = path.lib; 
		overlays = []; # the arg needs to exist but we can fill the overlays in the module
		
		# you can set the system here as below, or in your module, just like with NixOS 
		#stdenv.hostPlatform.system = "x86_64-linux";
	};
	modules = [
		{
			nixpkgs = {
				system = "x86_64-linux";
				config.allowUnfree = true;
				overlays = [final: prev: { ... }];
			};
			...
		}
	];
}

[stale[bot]]

Thank you for your contribution! I marked this issue as stale due to inactivity. Please be considerate of people watching this issue and receiving notifications before commenting 'I have this issue too'. We welcome additional information that will help resolve this issue. Please read the relevant sections below before commenting.

If you are the original author of the issue

• If this is resolved, please consider closing it so that the maintainers know not to focus on this.
• If this might still be an issue, but you are not interested in promoting its resolution, please consider closing it while encouraging others to take over and reopen an issue if they care enough.
• If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

If you are not the original author of the issue

• If you are also experiencing this issue, please add details of your situation to help with the debugging process.
• If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

Memorandum on closing issues

Don't be afraid to manually close an issue, even if it holds valuable information. Closed issues stay in the system for people to search, read, cross-reference, or even reopen – nothing is lost! Closing obsolete issues is an important way to help maintainers focus their time and effort.