-
-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
bug: Specialization does not work with nixos modules #3716
Comments
That's a fun one! cc @roberth @infinisil Minimal reproducer: with import <nixpkgs/lib>;
let eval = evalModules {
modules = [ {
options.hm = mkOption {
type = types.submoduleWith {
modules = [ ({ moduleType, ... }: {
options.foo = mkOption {
type = types.str;
};
options.special = mkOption {
type = moduleType;
};
}) ];
};
};
config.hm = { name, ... }: {
foo = name;
special = {};
};
} ];
};
in eval.config.hm.special.foo
A way to solve this would be to add a …
config.hm = { userName, name, ... }: {
foo = "${userName} / ${name}";
special = {};
};
} ];
};
in eval.config.hm.special.foo
EDIT NixOS/nixpkgs#218812 |
hm. I've been at this problem a couple of times now. I'd say I've also gone through some iterations of this in the NixOS vm test test matrix PR Eventually I settled on a solution that didn't need |
Home-manager could structure its specialisations module in the same way NixOS does, which happens to satisfy the same criteria. The non- That's a breaking change though, which is a bit un-fun. |
The breaking change does solve the lack of extensibility in the |
How? I don't see where the NixOS specialisation module does this. |
Not sure what you mean here, we could already add options besides |
Right, it doesn't, which could be a good thing. I assumed from the example that the |
I must have inferred too much / incorrectly from the example. The trace would be helpful. I wish people just posted traces, but I guess they consider them too verbose... EDIT: more reason for NixOS/nix#7553 I guess. |
Right, I simplified the failing example down to the bare minimum, so I removed the intermediate layer of submodule.
Aha, the following seems to work: diff --git a/modules/misc/specialization.nix b/modules/misc/specialization.nix
index 67e593e2..1f93ef00 100644
--- a/modules/misc/specialization.nix
+++ b/modules/misc/specialization.nix
@@ -1,4 +1,4 @@
-{ config, extendModules, lib, ... }:
+{ config, extendModules, name, lib, ... }:
with lib;
@@ -8,7 +8,7 @@ with lib;
options = {
configuration = mkOption {
type = let
- stopRecursion = { specialization = mkOverride 0 { }; };
+ stopRecursion = { _module.args.name = mkForce name; specialization = mkOverride 0 { }; };
extended = extendModules { modules = [ stopRecursion ]; };
in extended.type;
default = { }; |
And if |
If used inside the NixOS/nix-darwin module, we get conflicting definitions of `name` inside the specialization: one is the user name coming from the NixOS module definition and the other is `configuration`, the name of this option. Thus we need to explicitly wire the former into the module arguments. See discussion at nix-community#3716
If used inside the NixOS/nix-darwin module, we get conflicting definitions of `name` inside the specialization: one is the user name coming from the NixOS module definition and the other is `configuration`, the name of this option. Thus we need to explicitly wire the former into the module arguments. See discussion at nix-community#3716
If used inside the NixOS/nix-darwin module, we get conflicting definitions of `name` inside the specialization: one is the user name coming from the NixOS module definition and the other is `configuration`, the name of this option. Thus we need to explicitly wire the former into the module arguments. See discussion at #3716
Wow, that was fast. Thanks a lot! |
…y#3718) If used inside the NixOS/nix-darwin module, we get conflicting definitions of `name` inside the specialization: one is the user name coming from the NixOS module definition and the other is `configuration`, the name of this option. Thus we need to explicitly wire the former into the module arguments. See discussion at nix-community#3716
Are you following the right branch?
Is there an existing issue for this?
Issue description
Hello, I am trying to set up specializations for light/dark theme switching, but creating a specialization result in a build error.
The snippets that make my build crash is the specialization test"
Link to the full config
Maintainer CC
@rycee
System information
The text was updated successfully, but these errors were encountered: