Idiomatic configuration of home-manager in single-user NixOS

Help
1

Hi all! I have configuration of NixOS (+home-manager), developed for along time. It have single (personal) user view, which means all done for one single user (username of whom is configuration option).

By default home-manager suggests us to use it inside NixOS like this:

home-manager.users.<username>.service.git.enable = true;

Which in my case will look like next:

home-manager.users.${config.user.name}.service.git.enable = true;

This is too long line to copy-paste it everywhere where home-manager modules are in use.

For now I’ve worked-around this issue with creating option home of type attrsOf anything which value are copied to home-manager:

config.home-manager.users.${config.user.name} = config.home;

This worked well util I faced with necessity to use lib.mkForce value in home-manager option.

In this case the lib.mkForce value is reduced to direct value while copying to home-manager config.

How do I have to change the copying process to keep the lib.mkForce (and other similar) values or is there some other idiomatic way to implement the same approach?

2

So this is specifically in the case where you are interleaving NixOS and home-manager options, right?

Personally I think that is the issue, but if you really want to do that, your approach seems optimal here:

… after all, what you want is a new option that just happens to be equivalent to the home-manager module option, except with a different name.

You just need a different type to allow using lib.mkForce & co.; your option should be a submodule.

The issue I see is that it’ll be hard to get a handle on the type of the home.users attrset value without infrec, since you end up feeding the value back to that option. Unfortunately home-manager doesn’t expose this type in lib or anything.

So, personally, I’d try to get a handle on the option type, see if that results in infrec (not sure off the top of my head where module types fall in the fixed-point eval), and if it does write a home-manager PR that moves that option type definition to somewhere more accessible.

Or well, I wouldn’t interleave NixOS and home-manager modules to begin with, I still think that’s generally a lil’ weird.

3

I’ve been looking that what way, but found it too complex and thought there is better approach. Well will return to it then.

I’am perceive NixOS configuration as something which is able to atomically control my entire system, starting from hardware and finishing development tools.

So for example it configures at once how dm launches, which background it drawns, how it launch compositor, and launches lockers and wpaperd. So I have special module for monitors configurations with per-monitor wallpaper and dm config (from NixOS) and wpaperd and locker (from HM) config uses per-monitor configuration to syncronize wallpapers and monitors modes.

4

Yeah, you absolutely can configure both NixOS and HM in the same repository. The advice is just to avoid mixing the modules. You can have something like this:

{
   imports = [ (your top-level NixOS modules) ];
   home-manager.users.${config.user.name} = {
     imports = [ (your top-level HM modules) ];
   };
}

And then in your HM module for wallpapers or whatever, you can use the osConfig arg to access any options (standard or custom) you’ve defined on the NixOS side, the same way you use config to access options defined in whichever the current module system is.

{ config, osConfig, ... }:
{
  services.wpaperd = {
    enable = osConfig.custom.areWeWallpapering;
    # ...
  };
}
1 Like
5

In one of NixOS module:

imports = [
    (lib.mkAliasOptionModule [ "hm" ] [ "home-manager" "users" config.user.name ])
  ];

then you can use:

hm.service.git.enable = true;
1 Like
6

Still it looks like crutch. I have modules which controls both hm and nixos parts of same subsystem and splitting them will make more mess.

7

Perfect! I think, this is what I was looking for! Will try now!