introduce ezLib with funtions to import userModules

[dwagenk]

Previously adding a homeConfiguration to a host was only possible via setting ezConfigs.darwin.hosts.<name>.userHomeModules or ezConfigs.nixos.hosts.<name>.userHomeModules at the flake level. Importing a userModule inside a nixosModule or darwinModule was not possible.

This commit introduces

• ezLib.nixosImportUserModule
• ezLib.darwinImportUserModule functions to allow this usage. ezLib is part of specialArgs and extraSpecialArgs and thus available in modules by default.

I did not find a good place to document it yet. As it's not a flake-parts option there is no corresponding field for the documentation.

I use it similar to how it is outlined in the commit message.

[ehllie]

Thanks a lot for another PR! Is ezLib meant to be used for importing userModules inside host module like so?

{ ezLib, ... }:
{
  imports = [ (ezLib.nixosImportUserModule "alice") ];
{

Is it necessary to export ezLib in flake outputs of the user? Since all those functions do are create a module that imports the appropriate home-manager system module, and nest the user inside home-manager.extraSpecialArgs.imports. Why not instead create an attribute that will be passed to specialArgs of the system builder, named something like ezUsers or ezHomes which could be imported without having to use () inside the import list.

If this is meant to replace ezConfigs.{nixos,darwin}.hosts.<host>.userHomeModules, it would be nice to add a deprecation warning on that option. I would rather have only 1 way of doing things like embedding your home-manager configuration inside your host configuration.

[dwagenk]

Is ezLib meant to be used for importing userModules inside host module like so?

yes exactly!

Is it necessary to export ezLib in flake outputs of the user?

Probably not necessary, I was experimenting with also exporting the readModules function (separate branch), so grouping and exporting under ezLib felt like a good fit. Instead of exporting ezLib in flake outputs the specialArgs way would work to make the function available in modules. Also having the same function name for both nixos and darwin configurations would be possible this way.

Since all those functions do are create a module that imports the appropriate home-manager system module, and nest the user inside home-manager.extraSpecialArgs.imports. Why not instead create an attribute that will be passed to specialArgs of the system builder, named something like ezUsers or ezHomes which could be imported without having to use () inside the import list.

I tried this approach, but did not get it to work (infinite recursion). There might be a way to get this to work for userModules with passInOsConfig = false, although during experimenting I also tried that and did not get it to work. I'll gladly take hints on how to solve this, it would definitely improve the usability!

If this is meant to replace ezConfigs.{nixos,darwin}.hosts.<host>.userHomeModules,

For my usage: yes! I only want "generic" code in my flake.nix and declare the host-specific bits in the host-specific files.

it would be nice to add a deprecation warning on that option. I would rather have only 1 way of doing things like embedding your home-manager configuration inside your host configuration.

That's your call to make. If we agree on a way forward for this functionality I can add adeprecation warning for the old way to this PR.

[rcorrear]

Hi, I like the idea! I'd like to migrate to ezConfigs with parts and one thing I'd like is user modules in the context of a host. I have these in my own configs like "${user}@${host}".nix. From what I can tell this is not something that's directly supported by this PR but wouldn't be that hard to add, is that something that both of you would want to have? My use case is that I have multiple machines for which I want a base user module (like base git settings for example, or shell settings that span across machines), but more specialized stuff in host specific settings for a particular user.