It seems like home-manager being merged into Nixpkgs would reduce a lot of confusion. However, if there wasn’t a reason to keep the repositories separate, I assume they would already be merged.
So, why is home-manager separate from Nixpkgs?
Are things like home-manager’s home.file not declarative enough for Nixpkgs (but why isn’t everything but home.file merged?)?
I’m curious myself and I think this might help future forum-browsers.
It seems like you are implying that home-manager shouldn’t have been separate in the first place, but home-manager is something developed separately from Nixpkgs and is not an official Nix thing. It just depends on Nixpkgs. So if you’re saying that home-manager should be in NixOS/nixpkgs it would at least have to gain an official status from the NixOS team.
So to avoid confusion home-manager should have mentioned that it’s not NixOS official thing? I’m not quite sure what confusion you’re talking about here…
As for the technical details of merging a completely new major compartment into nixpkgs, in addition to the, I have no idea at all but I imagine it won’t be as easy as ‘they would already be merged’.
IIRC home-manager actually spun off from nixuser: declarative user environments by ts468 · Pull Request #9250 · NixOS/nixpkgs · GitHub mostly because developing it outside of the main tree allowed for more flexibility. While people were arguing about how to do it, @rycee just went and did it (and did a very good job at it I think).
@timokau I didn’t know this, very insightful. I guess this makes more sense as to his warnings: GitHub - nix-community/home-manager: Manage a user environment using Nix [maintainer=@rycee]
Ah, this makes more sense now.
I wonder if there is precedent for home-manager modules being merged into nixpkgs once stable. I understand they are separate projects, but I’d love to see them working together (e.g. for polybar).
If there’s not precedent nor a reason why at least one module can’t be merged, maybe I’ll open an issue on the home-manager repo asking for the thoughts of @rycee, et al?
EDIT: oops, didn’t mean to reply to dramforever specifically
I’ve not used home-manager, but I’m begining to think keeping “system” and “user” functions and state seperate is the right thing to do. That is however not to say that home-manager cannot be hosting in nixpkgs.
I opened the PR for a NixOS Polybar module and I will be the first to admit it doesn’t actually need to affect system state. If I had transitioned to HM I wouldn’t have made the PR.
Looking this question from the other side, we also have a seperate repository for hardware configuration, which I don’t believe has been considered for inclusion in nixpkgs. Both repos seem to have the problem of synchronization with nixpkgs.
The modules that are in home-manager aren’t equivalent to the one’s in nixpkgs at all.
They work at a per-user level, and the ones in nixpkgs are for the entire system.
As home-manager isn’t NixOS’s project, it’s that home-manager provides modules that extend or duplicate one’s in nixpkgs, per user. As it stands, I think this is becoming a problem.
Home-manager should have probably turned into an RFC to have some functionality like this in nixpkgs proper.
As home-manager isn’t NixOS’s project, it’s that home-manager provides modules that extend or duplicate one’s in nixpkgs, per user. As it stands, I think this is becoming a problem.
Thank you for phrasing this so well, @worldofpeace.
Some examples of duplicated modules: zsh, i3, compton.
Also, home manager’s package lists sometimes conflict with nixpkgs’s package lists in ugly ways (e.g. I cannot figure out how to enable git for root without package priority issues.
I imagine that a lot of duplicate features existed in home-manager first (is this true?). If so, it would be cool to see a process for moving modules from home-manager to upstream nixpkgs so that we have neither duplicated efforts nor duplicate modules.
Maybe we should ask @rycee what should be done about this.
I think this thread is a testament to how much mind-share home-manager has captured in our community. I put the bare minimum packages I need in configuration.nix and everything else in home manager. Been very pleased with it and no major issues on NixOS or Ubuntu, although didn’t work on CentOS. It’s worth noting that home-manager is in fact in nixpkgs already: https://github.com/NixOS/nixpkgs/blob/23aa5ff8783958bb39a02428fa566a944f8aad2e/pkgs/tools/package-management/home-manager/default.nix. Also, there is a way to use it as a NixOS module: https://rycee.gitlab.io/home-manager/index.html#sec-install-nixos-module
NixOS was separate and merged in, my guess is home-manager will be too, unless there is some many-repos flakes thing first (which I don’t believe is sustainable without static types).
For me the device evidence is the modules that are duplicated between the two. Secondarily, is things like nix-darwin which for better or worse blur the user-system distinction.
NixOS was merged because 1) we didn’t have flakes; and 2) there is frequently some tight coupling between packages and modules (e.g. if the systemd package is upgraded, it often requires changes to the systemd modules as well). Point 2) is probably not very applicable to home-manager.
It seems clearly preferable for both quality and speed of development to have projects like home-manager in their own repositories, since then 1) you can have whatever process is appropriate for a project of that size (e.g. you don’t have to go through the Nixpkgs PR / release process); and 2) you don’t have to give 100+ Nixpkgs committers write access to your project.
which I don’t believe is sustainable without static types
The Python ecosystem doesn’t live in a giant monorepo either and they seem to manage without a static type system.
It seems clearly preferable for both quality and speed of development to have projects like home-manager in their own repositories, since then 1) you can have whatever process is appropriate for a project of that size (e.g. you don’t have to go through the Nixpkgs PR / release process); and 2) you don’t have to give 100+ Nixpkgs committers write access to your project.
Oh, no, I definitely agree that some of home-manager should be in its own repo. That allows for a lot more flexibility than if the codebases were more tightly coupled.
- there is frequently some tight coupling between packages and modules (e.g. if the systemd package is upgraded, it often requires changes to the systemd modules as well). Point 2) is probably not very applicable to home-manager.
Ah, this is where I disagree. NixOS modules and home-manager are very closely related and don’t always interact well, especially for some of the duplicated functionality I listed above.
Regardless, I think we can agree that home-manager+nixpkgs will always be ahead of just nixpkgs. My question is, when nixpkgs wants to implement something that home-manager has, if there could be a process for merging one of home-manager’s existing modules instead of re-inventing the wheel.
If there is somebody willing and available to write an RFC about cherry-picking parts of HM in Nixpkgs then I’d be happy to assist in what little way I can. For example, the dagOf type would probably be handy in a few places in NixOS.
In general, though, I’m inclined to agree with @edolstra and don’t see much point in having HM as a whole merged into Nixpkgs. Perhaps the main benefit would be having a pre-build copy of the HM manual in the binary cache.
What I would be more excited about is an RFC for some form of library of stable “options only” modules. The idea being that different projects could import and endow them with a project specific config section. For example, it would be nice if I could more or less copy the services.postgresql attribute set from my NixOS configuration into my HM configuration to have my own PostgreSQL server, or into a project shell.nix to be started up by direnv, or into a single service Docker setup running without systemd, and so on.
Just to clarify. Home Manager is not a fork of nixuser and they, as far as I know, don’t share any code. That said, HM exists thanks to nixuser showing it was possible to do declarative user level management.
As it turned out, the basic functionality of installing packages, generating configurations, linking files into $HOME, and so on is actually very simple and it was pretty easy to just implement everything from scratch. If anybody is wanting to play around with the NixOS module system then I think this is a good weekend project.
I would propose to add home-manager to NixOS organization.
I think that sounds like a good idea, provided it can be done in a way that won’t break existing installations. Unfortunately I’m not having much time to devote to it but if somebody is willing to take lead then I’d be happy to help.
If you transfer a repository to a new owner, all links to the previous repository are automatically redirected to the new location (as long as the original owner doesn’t create a new repo with the same name again).
I agree with @lilyball, I think this is the way to go. Even git is happy with the redirection.
Will you please explain what improvements this addition would make?