Duplication home-manager and nixos modules

So I get that home-manager should be not merged into nixpkgs because of cross platform availability, but what I wonder is why is there not one way instead of multiple ways to achieve something?

I think nowadays, most people use home-manager in combination with a nixos system, and I would almost call it best practice for simple, declarative systems.

Let me illustrate this with an example:
Say someone wants to have Firefox installed, the best options would be a) enable it via nixos module: programs.firefox.enable, or b) enable it via home-manager module: programs.firefox.enable as well. I think this is really confusing for many people, because they do not know what way they should choose. Can we not get rid of these duplicate options, because we can assume most people would use home-manager.

There is probably a lot more to it than I described, but I would like to hear your opinions on this and why this should or should not be done.


The options are not duplicate. The NixOS option will set up the system-wide environment, whereas home-mamager only sets up a specific users’ environment. The NixOS module also lets you configure the system-wide settings, while the home-manager module only manages individual profiles.

Sure this will often seem equivalent if you only ever use single-user systems, but the difference is significant.

Is that the reason? Nixpkgs contains plenty of darwin support, this sounds a bit odd.


@TLATER but I think there are cases where home-manager modules have all options the system one has

Do you have examples? Even if the options overlap, user-specific and system-wide can by design almost not be represented in NixOS and home-manager respectively.



but how do i know if I chould choose system or home-manager module if I need the same options from either and I have only one user? Kind of confusing

1 Like

That’s for you to choose, and still pretty hard to assert anything about without an example.

Anyway, as a rule of thumb, does the program feel more tightly coupled to the user, and may travel between multiple systems along with your home-manager config - possibly even to non-NixOS systems - or is it tied to the specific device with its hardware? That’s how I tend to choose, since it makes it easier to maintain multiple systems.

And if you really don’t know, is it really so bad to just pick one at random?

Personally I’m more concerned with code duplication and the resulting maintenance overhead, feature drift, and actual problems caused by mismatching NixOS and home-manager versions. But none of those things will be solved by just blanket removing useful features, only a merge into nixpkgs would solve that.


@TLATER why did the merge not happen yet? I think the only problem with it are the evaluation times because nixpkgs gets so many more options. But besides that I see a ton of advantages

I don’t personally know. It’d be a fair bit of work, at the very least - it can’t be just a simple merge, since the options and how they work are quite different. Nonetheless, I think a fair few community members would love to see that, for the reasons I outlined as well as it becoming more “official”.

I am 100% for home-manager phagocytosis. After all, NixOS itself was phagocyted and the arguments for its flakification never convinced.
The same applies to HM, imho.


@TLATER @AndersonTorres should an rfc be opened for this? I think it would be a major step forwards.

I will certainly write one next week.
But, who wanna shepherd?

1 Like

I’d give it a try, but have never taken part in an RFC before, so may not be a good candidate for what is undoubtedly going to be a contentious RFC :wink:

Would probably be a good idea to involve @rycee in any discussion on this, too.

Looking forward to seeing where this will go, either way.

Thank you very much @AndersonTorres and @TLATER, I hope that we can eventually get somewhere with it. This has been bothering me for quite some time. I also know someone else who can shepherd, so I will tell him

I would say that the vast majority of “NixOS on desktop” users use a single user setup, and for these users there are no consequential differences at all between system and user packages.

Like, yes, there are differences in how this things are implemented, but if we look just at the behavior observable by the user in front of the screen, they are duplicates.

Which is one of my two main gripes with home manager — I run a single user system, and I only want to install system packages. I’d maybe love to take advantage of home-manager’s ability to generate some dotfiles, but not at the cost of adding a second way to install software.

The beauty of nix is that it’s still the same method of installing software when used on NixOS. All of it is in the nix store, installed by nix, coming from the exact same packages.

home-manager is just a different expression of their presence that makes them only visible in your user’s environment (and not for example root, or the other hundred miscellaneous system users your system has, even when it is “single user”).

I used to think similarly, I wanted my dotfiles to be decoupled from the packages. Over time I’ve accepted that you just can’t have functioning dotfiles when your systems use widely diverging software versions, things just always become incompatible.

You can also use home-manager’s dotfile management and add all the packages manually to environment.systemPackages if you really want all your packages to be in the same list, just force home.packages to be empty.


To clarify, I do want dotfiles in ~ to be synced with system package versions. The way I do this today is by storing my dotfiles and my flake.nix (which defines several hosts) in the same git repo.

1 Like

@AndersonTorres when you create that PR (rfc) for merging home-manager into nixpkgs, I guess it would also make sense to propose merging nixos-hardware directly into nixpkgs?

AFAICR nixos-hardware is a place for hackish things from buggy hardware quirks. Its purpose is similar to collect hardware oddities on a same place, like a knowledge database.

It also can become deprecated too fast - new hardware comes and old hardware goes.

It is more akin to NUR. I see no reason to include it under monorepo.


Brainstorming a bit:

  • As far as I remember, HM created some data structures. Maybe they can be factored and included into lib;
  • Duplication of code suggests factoring - a super structure from which nixos and hm can inherit
  • Merge the maintainers of both trees
  • New rules for ofborg and CIs in general

And a name: “All Your Home-Manager Are Belong To Us”. (No, the Borg was already taken.)


Not really — it started as a single (Subversion) repository, and the split was a mistake when moving to GitHub, and e.g. the committer lists were always shared. I think HM at some point refused the merge. Maybe the situation is different now.

So, a replacement for RFC78 from someone who doesn’t hate the module system? That could be useful.

1 Like