I’d like to manage my home with NixOS. But I thought it’s better to do that from scratch in NixOS instead of pulling in the large third-party mess. As long as we can manage packages, services and files in home, module maintainers can support user config optionally and gradually and HM can stay as a cross platform tool.
How is the code quality of Home Manager?
Given that this is not the status quo for neither Nixpkgs or NixOS, I do not see this as a requirement for merging or even relevant to the discussion.
I don’t see why you’d need any fancy tools here or why you’d even want to rewrite history; why not simply keep all the history in-tact?
All we need is one merge commit with the most recent Nixpkgs revision as its first parent and the most recent hm revision as its second parent. In the commit’s tree, all the hm stuff would be moved into the subdir. Diff visualisation tooling should correctly pick that up as renames if given a high enough rename detection limit.
I think this could be done using git subtree but you could always do it the dirty way:
- Prepare desired tree ahead of time
- Do a dirty merge
- Reset working tree to the prepared tree; resolving all conflicts
- Commit
I think that’s fine to keep for now. As long as it’s limited to the home-manager/ subdir, it doesn’t affect anyone else outside of super basic things like commit hygiene but I think hm is up to snuff there.
NixOS necessarily also still has “discrepancies” w.r.t. nixpkgs and that’s fine too.
Again, I don’t see why that needs to happen in step 1. Why couldn’t hm keep its CI setup as is (modulo code location)?
WDYM by “future package inclusions” and what does it have to do with home-manager?
What I think is missing is the community side of things.
How do we deal with existing issues? Will we simply transfer them over and attach a home-manager label?
What will happen to open hm PRs?
How do we deal with labels? How do we deal with issues/PR automation? (i.e. ofBorg, not sure if hm has an equivalent)
Should home-manager committers need nixpkgs commit access?
And isn’t the set of home-manager committers nearly a subset of the nixpkgs committers anyways? (Ignoring the current turmoil which I assume to be temporary.)
How should Nixpkgs’ release channels work with home-manager? Should HM CI block channel advancement?
Even important however, I do not see any representation of the existing hm community in the RFC; how do they want the future of home-manager to look like?
I’d require at least one core hm maintainer to co-author this RFC in order to take it seriously; the home-manager community must also want this, not just us Nixpkgs people.
One final note: I think it’d be very poor timing to turn this into an actual RFC right now, given the current uncertainty about who the Nix community actually is. I don’t see that being resolved any time soon and wouldn’t expect it to be resolved to a point where this sort of thing could be done in less than a year.
I could trivially see the hm community not wanting to merge with Nixpkgs purely due to the uncertainty around the NixOS organisation.
I’d prefer we waited until either the current community manages to rid itself of its toxic parts to be reasonably healthy or until a separate community overtakes it as the primary “Nix” community.
I could see the RFC process itself requiring an overhaul in either case.
6 Likes
There is at least one RFC that requires formatting. In a big enough amount of time it will happen.
I am merely anticipating the scenario.
Read this small block of text as “we have tools for doing this assimilation”, somewhat like a mathematician that writes “there is at least one solution”.
If you are correct, less one problem to think about!
As I said before, I am anticipating objections.
There are many packages that have HM modules as well as NixOS modules.
How such packages should be dealt in the future? Maybe a shared module that can be specialized later for each corresponding framework…
I am not aware of GitHub assimilation tools, but ideally they should be transferred to NixOS monorepo as well.
This is precisely what I was talking about the HM CI side.
Yes.
Most certainly.
This is why I opened this brainstorm topic.
Actually, it’s almost there: Enforce nixfmt for new/changed files, treewide reformat pass 1 [skip treewide] by infinisil · Pull Request #322537 · NixOS/nixpkgs · GitHub 
6 Likes
We do not need “HM”. We need user-level configuration management - with decent quality, contributed by people who actually read some of the systemd docs before writing systemd services.
To that end, we might benefit from making our module architecture more “system-agnostic” - i.e. one layer for generating configuration, and another layer for deciding where that configuration goes (in /etc, in /home/whomever/.config, …) The first agnostic layer can be consumed both within and outside nixpkgs, enabling the simplification of projects like hm and nix-darwin, or even used outside of nixos in the context of system-manager.
I believe [RFC 0163] Portable Service Layer by svanderburg · Pull Request #163 · NixOS/rfcs · GitHub proposed something similar but slightly different.
7 Likes
Well, why to reinvent the wheel? HM is battle-tested after all.
Yes, and I am watching it. When this RFC succeeds, it will make HM integration way easier.
I’m not suggesting to reinvent anything. I’m suggesting to leverage the existing configuration generation that we have to prevent having to duplicate code.
HM has basically no quality gate, I’d rather not import that entire codebase into nixpkgs just like that. And if anything, nixos is more battle-tested, so we should use the config generation that we already have.
4 Likes
HM’s quality review should actually be similar to Nixpkgs’s module part, really. Although they do differ in the way they handle service.
2 Likes
One of the most common questions I get on Discord is how to manage HM and NixOS together - how to weave them together. So, this proposal would meet a need where people want a unified system. I cannalso see advantages wrt services having a shared definition between system and user.
There are some positives, even though my first inclination is to adopt HM into the org, this proposal is more bold.
7 Likes
If you’re only talking about formatting, you should have said so.
To me it reads more like “refactor all the code to my personal preferences”, especially the “unwritten rules” part.
IMHO, if a rule is important enough to be decided upon in an RFC, it should at least be written down and it should probably have community consensus too.
It reads like a recommendation to use these specific tools to me.
If you know of likely objections, those should be addressed/discussed in the RFC text.
Have you talked with anyone about this who might object?
I see two options here: Either as you either keep things duplicated (nothing inherently wrong with that) or find a technical solution. Neither of these require broad community consensus.
I don’t see deciding that to be in scope for this RFC, that is if it requires an RFC at all.
Hm, before a public discussion such as this one, I would have at least expected you to have at least cleared this with the people it’d affect the most in private.
IMHO, consent-wise, it’s enough for us Nixpkgs people to be indifferent to the merge but the hm folks must explicitly want this to happen. Otherwise, I can’t help but feel that this would be seen as an unwanted takeover.
1 Like
I wouldn’t call it quality gate, but rather significance check. Many modules consist of an enable, package and extraConfig option which in itself is not very useful to have if there is a generic way to create a config file and add packages to the user config.
In NixOS we only miss the way to create the user based config files in a structured way.
If there are no config checks or pre done settings or integrations into other modules, then the module lacks significance or “value” and would be likely declined in review.
Also there are good examples of what things can be managed with home-manager like gitconfig and also rather terrible ones like the config files for the Plasma Desktop.
7 Likes
Ideally both channels would be merged.
The modules are very readable, similar to those from NixOS.
The harder part is the Bash scripts, as expected.
This is basically what HM does - it uses the existing module system in order to generate configuration.
The duplication happened mostly because they are not in the same repo.
I beg to differ.
I announced my intent in their Matrix channel, a not so long time ago. For the sake of announcement I will do another right now.
There’s no real testing or even code review, stuff just gets merged if it “looks good”. For concrete examples, the sway and waybar modules were so awful I reworked my config just to get rid of HM. Even their systemd “abstraction” is not really an abstraction, just a straight toINI that doesn’t account for upstream service files.
Again I want to reiterate: the need is not for HM, the need is for user-level config management. The only reason HM keeps coming up is that it’s currently the only well-known option in that space. We can do much better.
4 Likes
I was not so lucky in my personal experience.
How much longer we should wait for those “we” that “can do much better”?
3 Likes
I didn’t say it with folding HM into nixpkgs in mind, but I have previously wondered aloud if moving module-related utility logic towards package passthrus might build leverage by enabling more reuse across module systems and dev shells.
I think the last time I mentioned it was in:
6 Likes
Yes we should merge it into the Nixpkgs/NixOS repo, so we can start deduplicating with NixOS, as others have said.
5 Likes
Kde configuration requires to alter their files in place as it too often uses the same file for both configuration and state
1 Like
I think we should create several middle grounds between the package and the NixOS modules (which must be used as a whole for now), including service abstraction, wrapper abstraction and dotfiles abstraction. We may need several RFCs to advance this.
4 Likes
The RFC process is all out of sorts (as someone far removed from it, admittedly) but perhaps folks can point me to stuff for nix RFCs and such that sorta kinda mirror what’s in here (process, roles, etc) https://www.rfc-editor.org/rfc/rfc6635.txt - we’re not that important but seems like a good document for sharper eyes to peruse and gather takeaways from (if they have yet to do so). Anyway, I sorta like this idea and the need for “user-level configuration management” grows by the day