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:
- Integrate it properly in the official docs
- 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)
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 
)
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