add homeManagerModules

[cdmistman]

like #223 does for nix-darwin modules, it'd be great to encourage broader sharing of home-manager modules.

[terlar]

I know in the wild there are:

• homeManagerModules
• homeModules
• hmModules

I am not sure if the community ever decided on one way. Anyways, this should probably live as a flake part integration in home-manager? And not in the base flake-parts?

[cdmistman]

i'm not sure if the community ever settled on one, but homeManagerModules aligns most with the naming conventions elsewhere and is the most explicit.

regardless, i think it's better to have this in flake-parts, so 3rd party flakes don't need to add home-manager as an input when they don't use any other home-manager flake outputs.

[roberth]

Ideally, home manager picks an evalModules class name, and then we can add a generic flake.modules.<class>.<module name> option, to support all the module system applications in one go. Basically that means to finish

• 213

Maybe even add it to the core modules.

Anyways, this should probably live as a flake part integration in home-manager?

That's generally how flake-parts is intended to be extended. Some reasons:

• Give control to the authors of that project, so that they are free to manage their "entrypoint" as is right for that project.
• Let users pick the integrations they want, without having to fight a built-in module (which could become stagnant).
• No unnecessary dependencies or undeclared hardcoded input names. (Nixpkgs is an exception I'd like to get rid of in this regard)

homeManagerModules aligns most with the naming conventions elsewhere

I'd recommend evalModules { class = "homeManager"; } to them then. EDIT: Done: https://github.com/nix-community/home-manager/pull/5339

better to have this in flake-parts, so 3rd party flakes don't need to add home-manager as an input when they don't use any other home-manager flake outputs.

That would be a fair reason, but I do think the generic solution (#213) is preferable.

Perhaps unrelatedly, a module that sets homeManagerConfigurations should definitely live in the home-manager repo, because that's not as simple, and it requires an actual home manager, which is naturally available there.

[cdmistman]

oooooh i didn't see #213 - that looks like a much better solution :) thank you!