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?
There was a problem hiding this comment.
Hey!
My 2cents to the _question: /homes/USERNAME seems better suited, as you both wrote (, because HM will pick up the output name).
lib/default.nix
Outdated
| }; | ||
|
|
||
| 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 commit removes the 'users' attrset, as it doesn't give users anything they can't get from referencing the file path directly. Referencing the file by path makes the dependency tree more obvious. This commit can (should?) be squashed into its parent before merge.
| # FIXME: Find another way to make this work without introducing legacyPackages. | ||
| # May involve changing upstream home-manager. | ||
| legacyPackages = lib.optionalAttrs (homesNested != { }) standaloneHomeConfigurations; | ||
| legacyPackages = standaloneHomeConfigurations; |
There was a problem hiding this comment.
iiuc, we only introduce this to have nested attributes because the home-manager cli doesn't understand flattened ones? If that's correct I think it'd be preferable to drop this here before it sees too much use and prioritize an upstream fix. What do you think?
(I know it's already in main, i just hadn't seen it before and took the change as there's already this PR touching it ;))
|
Hey (@clo4 ?), may I kindly ask for some progress update here? I wanted to use clo4's branch, but it seems not in sync w/ blueprint's main branch. Thanks in advance + KR |
5 participants
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