Closed Frontear closed 2 months ago
Also may be useful to use lib.mkAliasOptionModuleMD
, see <nixpkgs/nixos/modules/config/users-groups.nix>.
config.meta
is a property in nixpkgs/nixos/modules
, so the naming is a weird clash that I'm not keen on.
We now have my.users that provides essentially the functionality I wanted, but at a level that only applies to a specific user.
It's honestly a little funny thinking about it now because it essentially does exactly what I want, so even if my.users.different wishes to set things up, it would be in my configuration.
It's not a strict necessity for me to migrate to having real options, but it is rather funny.
Having a wrapper that then needs to be referenced directly through
config.main-user.name
is a digusting hack and I'd rather not need it at all. Honestly a complete waste of the module system and accomplish nothing more than holding the information of another module, like a variable + function callback.I have 2 ideas that I could attempt, both arguably more "nix-y" and a lot better.
The first idea is to have a meta attribute set, perhaps either as an import, a flake output, or simply a
specialAttr
input passed in for every module. This will contain information about hostnames, timezones, locale, usernames, stateVersion, and possibly more.The second idea is to leverage the NixOS attribute of
users.users
and create ausers.users.main-user
with all the properties set. Problem with this is that it introduces repetition because the nixpkgs issue still stands with infinite recursion, so I would need to manually sethome-manager
andenvironment.persistence
. Not ideal.No idea which way I want to go but it's a good consideration.