Why isn't more of home-manager merged into 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.

8 Likes

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.

1 Like

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

8 Likes

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.

2 Likes

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.

10 Likes

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.

  1. 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.

4 Likes

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.

4 Likes

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.

1 Like

I would propose to add home-manager to NixOS organization.

14 Likes

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.

8 Likes

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).

4 Likes

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?

Moving home-manager to Nix/Nixpkgs/NixOS · GitHub increases discoverability (i.e., the ability to find nix-related projects) and gives some official endorsement to the project.

2 Likes

It also means that release of NixOS and home-manager can be coordinated together with the RM’s and @rycee. Since the past maybe two releases, I’ve noticed several changes in NixOS that had unintentional side-effects on home-manager. Having this would allow NixOS contributors the opportunity to have a greater focus on those issues because it would be our project.

5 Likes

Tnx. I’ll install it then.

As an aside, should we start mentioning the availability of home-manager as an option in the NixOS manual? As it stands, that section doesn’t really represent the status quo imo.

8 Likes

To amplify what @workflow says: my initial impression of Nix was that it provided the functionality that home-manager actually provides. I think there’s a lot of room for better marketing, documentation, and clarification around home-manager’s place in the whole Nix ecosystem. I think it’s very confusing for newcomers.

2 Likes

What would worry me quite a bit is if development on some nixpkgs modules will become stalled, because developers decide to better commit to the equivalent module in HM.
Looking at the module for fish, for example, I can see that the nixpkgs variant lacks basic functionality like specifying plugins. It looks like attention has been turned away by the more sophisticated HM module.

Now people will visit search.nixos.org to list the options for fish and think that this is all what nixos can offer.

I have to agree that stuff being scattered around made it more difficult to get started with nix/nixos.
And now having to search 2 different websites for modules is a bad thing.

If most people agree that HM has become an important part of the nix ecosystem, I’d propose:

  1. Integrate it properly in the official docs
  2. Make it discoverable via search.nixos.org

Also it might be worth to think about a criteria to decide in which project a module should reside.
For example, If everyone agrees that the configuration of shells is a user specific thing, why not delete all zsh/fish related modules from nixpkgs completely? There will be less confusion for users and development/maintenance will be more efficient.

16 Likes