feat: home configurations without hostname #77
Conversation
Blueprint now supports defining user configurations in the top-level 'users' directory, and makes this a first-class way to share user configurations without exposing them in the public interface of the flake. Users are created in 'users/<username>/home-configuration.nix' (though this is easy to change in the future). Existing home configurations can access all the generic configurations through the new 'users' argument. For example, a user defined at 'users/baz/home-configuration.nix' could be imported and used as a base by 'hosts/foobar/users/baz.nix' (`imports = [ users.baz ];`) OR as a standalone configuration without a hostname. Editorial: new users should still be encouraged to start creating their configuration per-machine to reduce the complexity of their config, and only move to a shared config when they _need_ to share it between multiple devices.
|
Reviewers, how do you feel about the design? This PR exposes a My thinking here is that the users folder should be used for shared home configuration that isn't exposed as part of the flake's public interface. |
| in | ||
| lib.filterAttrs (_name: value: value != null) users; | ||
| in | ||
| importDir (src + "/users") mkUsers; |
There was a problem hiding this comment.
I wonder if /homes would map more naturally for the end-users. It would also allow users to have multiple home configurations (eg: homes/terminal and homes/desktop).
There was a problem hiding this comment.
I'm not opposed to this. users is analogous to hosts/*/users so it was an obvious first choice, but it also makes sense because HM will pick the output name based on $USER. @jzbor since you'll be using this yourself, do you have any input?
| @@ -128,6 +128,10 @@ let | |||
| self = throw "self was renamed to flake"; | |||
| }; | |||
|
|
|||
| hmSpecialArgs = specialArgs // { | |||
| users = homesGeneric; | |||
There was a problem hiding this comment.
Can you give an example of how this would be used?
There was a problem hiding this comment.
/hosts/foo/users/foo.nix
{users,...}:
{
imports = [
users.foo
];
home.packages = [
pkgs.hello
];
}
now the home-config foo@foo is the same as foo but with pkgs.hello installed
There was a problem hiding this comment.
Concretely,
(source)
It's just as easy to add "${flake}/users/robert/home-configuration.nix" to my imports, which is what I was doing before, so I don't have any strong feeling on whether this should be kept or not. I may actually lean towards get rid of it.
|
by the way, i dont know if you have added this, but if |
|
@JumpIn-Git HM handles this already based on the |
This PR will be marked as draft until there's consensus on what the right design is and a solid implementation for it. This PR only exists since I needed a place to put the to-do list, and since the feature probably be merged in some form eventually :)
This might not be the final form this takes, so I'm not going to describe it in detail in the PR. The commit descriptions will be up to date.
To-do:
See #74 for design considerations