-
-
Notifications
You must be signed in to change notification settings - Fork 2k
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 shared home-manager configurations between all users #594
Comments
I use something very similar to you, by assigning one home-manager config to multiple users, and this has not broken my setup. Perhaps it's something specific to you? Can you point out how it's setup on your side? Here's how it's setup on my side:
I love it 🤣! |
Your configuration gave me the original inspiration for my version. The difference is that I use |
Ah, this was unfortunate! I think to fix it one would have to change |
home-manager implementation was broken as it is now referencing `users.users` too: nix-community/home-manager#594 'nixos-module-user-pkgs' feature has introduced circular dependencies as blox already establishes a reference between the too attributes where the dependency link has the opposite direction. /-------- via blox -------\ | | | V /-------------\ /--------------------\ | users.users | <------ | home-manager.users | \-------------/ \--------------------/ This has been fixed by using the already existing `blox.users.users` convenience attribute to derive both `home-manager.users` and `users.users`. /------------------\ /-- | blox.users.users | --\ | \------------------/ | | | V V /-------------\ /--------------------\ | users.users | <------ | home-manager.users | \-------------/ \--------------------/ WARNING: This breaks configurations which doesn't use `blox.users.users`.
home-manager implementation was broken as it is now referencing `users.users` too: nix-community/home-manager#594 'nixos-module-user-pkgs' feature has introduced circular dependencies as blox already establishes a reference between the too attributes where the dependency link has the opposite direction. ``` /-------- via blox -------\ | | | V /-------------\ /--------------------\ | users.users | <------ | home-manager.users | \-------------/ \--------------------/ ``` This has been fixed by using the already existing `blox.users.users` convenience attribute to derive both `home-manager.users` and `users.users`. ``` /------------------\ /-- | blox.users.users | --\ | \------------------/ | | | V V /-------------\ /--------------------\ | users.users | <------ | home-manager.users | \-------------/ \--------------------/ ``` *WARNING*: This breaks configurations which doesn't use `blox.users.users`.
I have fixed this issue on my side. I have already created my own Thank you for the effort you have put in investigating this. |
Fixes a regression of GitHub issue nix-community#594. Before this commit, attempting to dynamically configure home-manager with contents of nixos's users.users when using the nixos module would result in infinite recursion. Fixes nix-community#594
Is there any recommended way to do this nowadays? Using perhaps, only home-manager ? |
Thanks for fixing, @rycee -- I use this and it's a nice feature |
This recursion can be solved by pulling config from within options.users.users = mkOption {
type = types.attrsOf (types.submodule ({name, config, ...}: {
config = mkIf (config.enable && cfg.useUserPackages && (lib.hasAttr name cfg.users)) {
packages = [cfg.users.${name}.home.path];
};
}));
}; this allows doing funky stuff with users.users like intersecting with home-manager modules eg, {lib, /* custom arg */ flake, config, ...}: {
home-manager.useUserPackages = true;
home-manager.users = builtins.intersectAttrs (lib.filterAttrs (_: v: v.isNormalUser) config.users.users) (flake.outputs.homeModules.users);
} I can do a PR with this change |
…values in users.users fixes nix-community#594
…s and nixos users configuration Pushing users.users.<name>.packages from matching home-manager users leads to a circular dependency when one attribute set is calculated from the other. A configuration pull approach replaces the previous one to break up the circular dependency. This new approach allows more flexibility in configuring both option sets, including calculating from each other. EXAMPLE; ```nix {lib, /* custom arg */ flake, config, ...}: { home-manager.useUserPackages = true; home-manager.users = builtins.intersectAttrs (lib.filterAttrs (_: v: v.isNormalUser) config.users.users) (flake.outputs.homeModules.users); } ``` EXAMPLE; ```nix {lib, /* custom arg */ flake, config, ...}: { home-manager.useUserPackages = true; home-manager.users = { inherit (flake.outputs.homeModules.users) demo-user; }; users.users = lib.mapAttrs (_: _: { isNormalUser = true; }) (lib.filterAttrs (_: v: v.programs.git.enable) config.home-manager.users); } ``` fixes nix-community#594
#549 is broke my configuration. I have created a NixOS module where I can declare a "shared" home manager configuration which is applied to all users managed by nix. I use this approach to generate homogeneous user environments.
The above mentioned change introduces infinite recursion because now home-manager writes the
users.users
attribute.I can work around this problem but I thought that it worth to mention this use case [1]
[1] Upon writing the issue description I remembered this xkcd comic https://xkcd.com/1172/
The text was updated successfully, but these errors were encountered: