Brainstorm for RFC: Assimilate home-manager into Nixpkgs monorepo

Well per what I wrote in Brainstorm for RFC: Assimilate home-manager into Nixpkgs monorepo - #29 by Ericson2314, I don’t think we should wait for 163. Rather, 163 should ask politely we merge some repos first to enable experimentation, and indicate we’re serious about deduplication.


I think that a good way to approach this would be to think about creating some primitives for managing files in home directories (or contested directories more generally where Nix is not the only thing in charge) and then build on top of that.

As others have mentioned there are many modules in home-manager of variable quality so I would be very picky about what to assimilate and what to rewrite.


That’s RFC163 in a nutshell. It’s been stuck for a while, as would be expected for such a major architectural concept.

I think @Ericson2314 is right that waiting for it is a bit pointless; there’s no reason such a change can’t happen after a merge. Meanwhile, a merge can already help get some smaller improvements done, and makes any eventual huge architectural refactor just a tad easier since it won’t be 10 PRs on multiple, very active repositories.

If the only remaining concern is module quality, well, nixpkgs has its fair share of undermaintained code too, it’s not like nixpkgs is overly strict (though it has been improving). Simply having home-manager present in a subdirectory won’t affect the quality of other nixpkgs components anyway, so it doesn’t feel like the impact would be that big.


RFC163 seems to have two parts: 1. generate service configs; and 2. stick them in the right place. Part 1 seems to have gotten all the attention (and doesn’t seem to be making much progress) while I haven’t seen that much discussion about part 2.

So I think we should think more about this second problem and forget about services for the time being. Many home-manager modules don’t use services and simply generate a few configuration files in $XDG_CONFIG_HOME. home-manager currently has a systemd service that links files to the correct place but I’ve been dissatisfied with that for a while… Perhaps there is a nicer way to do this using unionfs/overlayfs mounts on Linux?

1 Like

Well, if you don’t need to wait RFC 163 in order to inject HM onto the monorepo, then better!

If the idea is to do some incremental migration, then we need some proof-of-concept:

  1. migrate the machinery needed to accomodate the HM modules
  2. migrate a small module, say Fluxbox
  3. migrate a big module, say Emacs

But I am not so versed on that minimal machinery; I need to study this.


@roberth had idea of sharing one of the modules for Nix itself between both projects. I think that alone would be a good and sufficient proof of concept, for me.

Personally, I recommend the dotfiles approach (Yes it requires much more work but it’s simpler for the user to use in the end), we could also adopt a hybrid approach where provide dotfiles/modules when we can and the user can use wrappers when there aren’t any.

The nice thing about wrappers is you can easily send part of your closure (i.e. just VIM + vimrc) to another machine without having to deploy the whole home-manager.

TBH I thought wrappers were always the ultimate end-goal for managing home but /shrug


Wrappers looked a bit ad-hoc, until I looked at wrapper-manager: