Why isn't more of home-manager merged into nixpkgs?

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

The Python ecosystem doesn’t live in a giant monorepo either and they seem to manage without a static type system.

Python ecosystem does suffer from some… complications that are in part related to dynamic typing: Developer | TechRepublic (I’m pretty sure I saw Guido’s own tweet on the matter, but couldn’t find it)

In particular, lack of explicit static types makes nix/nixpkgs significantly harder to grasp (and, at first, plain overwhelming)

@7c6f434c’s https://github.com/NixOS/rfcs/pull/78 is supposed to help with this, btw.

2 Likes

Surely not with all of this, but hopefully even with separate repos we could reach a solution making the bulk of the code easier to port between the two sides.

1 Like

Yeah I mean to say your RFC is a first step in the right direction :).

2 Likes

This reminds me of GitHub - svanderburg/nix-processmgmt: Experimental Nix-based process management framework - I wonder if home-manager and NixOS aren’t exactly the same project but with differing module systems, and if an agnostic process management layer wouldn’t enable having both systems with one codebase.

If you squint a bit, both HM and NixOS are profile-based process+file tree managers. They both activate profiles built out of modules. One difference is that NixOS is multi-user, but that basically only surfaces in module configurations and scripts.

So, maybe if we tune our abstractions a bit, then the only difference between a user profile, a container profile or a system profile, is the configuration you use to generate them?

(I may be overlooking some insurmountible difference of course, apologies if so :slight_smile:)

I agree with you that these tools look too similar to be so different :-). Maybe https://github.com/NixOS/rfcs/pull/78 will solve this.

1 Like

I’d really like to see nixpkgs and home-manager somewhat converging together a bit, at least having nixpkgs provide some of the “low-level, generic plumbing”:

We already have users.users.<name>.packages to describe per-user packages in nixpkgs, and some (slightly broken) code for per-user service restarts.

However, there’s no way to specify from nixpkgs for which user a certain systemd user unit should be active - with nixpkgs, we can currently only install (and enable) a service for all users, leading to issues like Systemd units don't have an [Install] section · Issue #108643 · NixOS/nixpkgs · GitHub.

home-manager allows per-user enabling (of home-manager services only), and brings its own unit activation script.

IMHO, per-user unit enabling and per-user activation scripts should be provided by nixpkgs, and home-manager could make use of that, and bring its own modules which aren’t generic/stable enough to be in nixpkgs.

14 Likes