-
Notifications
You must be signed in to change notification settings - Fork 108
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
Profiles imports are brittle, causing failure if imported twice #136
Comments
I can't reproduce this error in either core or community from a fresh checkout. What revision are you on? The only place I set the default shell for users is: https://github.com/divnix/devos/blob/community/profiles/develop/zsh/default.nix#L9 This doesn't conflict with users.users.<name>.shell though, as I tested it explicitly, and this is only set if your using the community branch and develop or zsh profile. You might want to grep around and see if you accidentally set it twice somewhere, or perhaps this was an issue with an older revision but is now resolved. Worst case scenario, you can always force the setting with I'll leave this open for a bit to help you find a solution. |
OK, I've found the error. It seems like if you import a profile twice, it does weird things. Here's what happened:
So everything in the profiles Maybe a hint in the manual would be fitting if this is the case? |
Good catch, we don't want this biting us in the future. Perhaps the profiles attribute set in suites should just contain paths to the profile, instead of importing it outright. The default import logic prevents this sort of error when importing the same path twice, so we might want to just leverage that. |
I just found out it can also happen when importing a profile inside suites and then importing it inside another profile like this: {
suites = with profiles; rec {
[...]
pc = graphics ++ [ develop networking.samba printing systems.pc virt zfs ];
laptop = pc ++ [ systems.pc.laptop ];
};
} and {
imports = [
../. # this imports pc
];
} |
* Leave importing to nixpkgs module implentation. Provide a path instead; resolves #136. * Allow profiles which are not lambdas but simple attribute sets, relaxing the constraints a bit. * Update profile README.md * defaultImports -> mkProfileAttrs: allow importing subprofiles even if parent directory does not contain a default.nix.
Thanks, seems to work now! |
Expected Behavior
If I set
users.users.<name>.shell
in theusers/<name>/default.nix
file, there should be no conflicts anywhere (happens for any user).Current Behavior
Building the system configuration errors out with following:
for
users.users.<name>.shell = pkgs.zsh
:Possible Solution
Maybe I have to set it somewhere else? Can't find anything in the documentation...
The text was updated successfully, but these errors were encountered: