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.
6 Likes
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.
3 Likes
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.
4 Likes
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:
- migrate the machinery needed to accomodate the HM modules
- migrate a small module, say Fluxbox
- migrate a big module, say Emacs
But I am not so versed on that minimal machinery; I need to study this.
2 Likes
@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.
3 Likes
https://wiki.nixos.org/wiki/Wrappers_vs._Dotfiles
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
2 Likes
Wrappers looked a bit ad-hoc, until I looked at wrapper-manager:
3 Likes
So what the future of this RFC?
Well, I want to talk with the Home Manager maintainers before taking the final step of opening the RFC.
By the way I sent a message to @rycee via Matrix, I am waiting a reply.
5 Likes
Honestly this is the end game for Nix.
I started down this path but it is next level difficulty lol.
1 Like
I will wait more three days, and regardless any return from Rycee, I will work in a draft for pull request.
6 Likes
Any progress on that draft? 
2 Likes
Yes: I have put it on my local fork.
9 Likes
Until the RFC PR has been made, I think it’s worth sharing here a take on home-manager by @viperML
I mostly agree with the things said and, with or without this blog post, I prefer the alternative of writing what home-manager does from scratch, for reasons I would rather detail on the RFC PR itself.
9 Likes
I want to add, that in the context of this RFC, some of the complaints I have with HM might not make sense. E.g. new people would step in for governance if HM were to get moved into nixpkgs. But I see two outcomes:
- HM is assimilated as is. In that case, some issues persist (
mkOutOfStoreSymlink, file backups, the profile shenanigans, option duplication, etc). - HM is heavily refactored before being assimilated. This might be a long process, which would need a lot of workforce. Breaking changes will happen, which is bad for end user experience.
Perhaps I would have more stuff to add, but those are my first impressions
6 Likes
I also agree, I think home manager would have to be very heavily refactored imo to uh not be insane lol.
3 Likes
Or better yet just bail on HM it seems to have a lot of technical debt, we should honestly just create a tool from the grounds up.
1 Like
We can either work our way up to match HM while taking inspiration from it, or work our way down by chipping away at HM imperfections that we want to remove. Either way we will hurt the end user experience as Fernando mentioned – which, IMO, is worth it.
If we adopt HM even, there would need to be some level of coupling with system NixOS modules for a good nixpkgs architecture. I think that’s what needs to be discussed thoroughly in the RFC. If we’re going to do some coupling, which would likely push for some effort downstream, IMO, we should take the bigger leap here, learn from HM’s mistakes and not propagate bad patterns at the cost of some more effort downstream.
Of note is that none of this will break anything since it’s an opt-in for downstream. It simply means that it won’t be a drop-in replacement for those who do opt-in.
1 Like