Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should Nix Have a Home Management System? #83

Open
nyabinary opened this issue Sep 26, 2024 · 10 comments
Open

Should Nix Have a Home Management System? #83

nyabinary opened this issue Sep 26, 2024 · 10 comments
Labels
question Further information is requested

Comments

@nyabinary
Copy link
Contributor

nyabinary commented Sep 26, 2024

Question

Do you support the development and integration of a native home management system into Nix (similar to Guix Home)? If so, how do you envision this system improving the overall user experience and system management, particularly in terms of configurability, security, and ease of use? What challenges do you foresee in implementing such a system, and how would you address them?

Candidates I'd like to get an answer from

No response

Reminder of the Q&A rules

Please adhere to the Q&A guidelines and rules

@nyabinary nyabinary added the question Further information is requested label Sep 26, 2024
@mschwaig
Copy link
Member

mschwaig commented Sep 27, 2024

There is https://github.com/nix-community/home-manager that fills this role.

Using home-manager is one of the easiest, lowest-risk ways for people to get started with using Nix to manage part of their system declaratively, so it's something I like to point new users towards.
Personally, for the benefit of those new users I think it would be nice if the project name included ´nix´ or the project was part of nixpkgs, but those thoughts should lead to asking people questions, they are not a good basis to make a decision like that.

People have been discussing the possibility of merging home-manager into nixpkgs recently. Something like this should only be done if the maintainers of the home-manager project are in favor of it, and enough people on the nixpkgs side are confident that it is also the right thing to do for nixpkgs.

If you are asking about the creation of some new home management system, there is an RFC about such an effort, and I agree with the following comment on it: NixOS/rfcs#182 (comment).
Another home management system that can only come from the community and not be blessed in advance by the SC or developed in nixpkgs. It would have to get started outside of nixpkgs for practical reasons anyways, where it does not matter what the SC thinks.

@tomberek
Copy link

As stated by @mschwaig, this is role is currently filled by home-manger. Better integration would clearly benefit users and home-manager is a significant driver of Nix adoption. Therefore, I would support home-manager if they choose to become an official project and/or incorporating it into Nixpkgs, or another community-led effort in a similar space. Our role would be to help coordinate with the home-manager maintainers, or to ensure that additional resources related to incorporation into Nixpkgs are available (eg: for building + testing).

The concern here is that such integration is also the creation of a default, making alternatives less likely. I do not yet have a strong opinion on a specific direction to take, but welcome any input on the matter if someone has interest.

Side-note: I do think there is room for an abstraction in the Nix ecosystem to accommodate the "eval - build - apply" workflow. The "apply" (or "activation") has been a part of nix-shell, nix develop, home-manager, nixos-rebuild, NixOps, morph, and other tools. This is a common pattern that would benefit from reuse and incorporating the lessons learn from the existing experiments.

@NixOS NixOS deleted a comment from ysndr Sep 29, 2024
@kloenk
Copy link
Member

kloenk commented Sep 30, 2024

For me I quite like that nix is modulare in the sense that you can just plug in an external home manager. I'm not integrating a home manager, but I would always like to keep the flexibility to also allow new ideas just plugged in as out of tree module

@lovesegfault
Copy link
Member

I do not have a formed opinion on this.

On one hand, home-manager has been tremendously successful with things as they are, and I do not see a strong reason to change it. On the other hand, I also don't see a major downside to merging it into nixpkgs.

Generally, though, I think @tomberek hit the nail in the head: we should strive to strengthen our abstractions around how tools like home-manager, nixos-rebuild, NixOps, etc. work to encourage innovation in the space.

@getchoo
Copy link
Member

getchoo commented Oct 2, 2024

Do you support the development and integration of a native home management system

Given the popularity of home-manager, I believe the community definitely has a large interest in Nix for this purpose. Bringing it or something similar in as an official project would only make sense IMO

into Nix (similar to Guix Home)?

Integrating this into Nix the package manager may be a bit of a misstep, though. I would like to see this be closer to the implementation of nixos-rebuild, which by being in the nixpkgs monorepo ensures that there are no need to sync changes between the nix implementation of the tool and the modules, packages, etc in nixpkgs. Further, keeping it in nixpkgs would allow for easier reuse of our existing infrastructure, the introduction of abstractions between them as mentioned above, and faster iteration since we wouldn't be locked to nix's release cycle. nix would be best use as a plumbing tool for these systems, as it already is with nix-env/nix profile

If so, how do you envision this system improving the overall user experience and system management, particularly in terms of configurability, security, and ease of use?

Right off the bat, having this officially included would be a great leap in UX and ease of use. As I've heard from many first starting out with Nix, home-manager is a bit of an odd concept and intimidating with it being a completely separate community project that has its own setup; making an official tool that can be easily be bootstrapped with only nixpkgs alone would fix much of this issue. It would also introduce many opportunities for documentation on other official resources such as nix.dev

Regarding configurability and security, the greater attention nixpkgs has from the wider contributor base would allow for faster reviews with improved quality -- which in turn commonly leads to more and better thought out options -- as well as rapid responses from our dedicated Security Team

What challenges do you foresee in implementing such a system, and how would you address them?

Easily the biggest aspect would be the maintenance burden. In order for something like this to work and not result in a lot of reimplemented concepts, we need abstracts for sharing options between modules and managing the profiles that they declare. Nothing like this really exists currently though (to my knowledge), so it's probably something for a dedicated RFC and improvements to the modules system in general

@roberth
Copy link
Member

roberth commented Oct 6, 2024

As said, it already does, in the form of Home Manager, and that's great.

Perhaps something could be optimized about the installation process and/or the CLIs, but putting the nix command between Home Manager and its users would only serve to stifle Home Manager's ability to improve its own command.

I don't know how Debian works anymore, but I don't think Debian users consider themselves primarily dpkg users, so then why should Home Manager users have to use it through nix?

@proofconstruction
Copy link
Contributor

home-manager has been a great gift for desktop users, enabling configuration of many different and unrelated pieces of software with the same Nix module system. I use it to define configuration for several tools I rely on, and I'm very grateful for its existence; it was one of the features that originally made me fall in love with NixOS on the desktop, and I also know this to be true of others in the community: its value as an onboarding nice-to-have cannot be overstated. However, the current implementation suffers from some significant drawbacks which merit reevaluation before it could be reasonably upstreamed. I would support a desktop-focused UX team addressing these issues.

@asymmetric
Copy link
Contributor

Personally yes, I think it should. I think NixOS on the desktop is one of the on-ramps for a lot of people (it certainly was for me), so having a polished and coherent story around that would IMO be great for adoption. People who gravitate towards something like NixOS on their desktop IME tend to be software engineer/DevOps types, who might then want to use it at work as a server distribution, spreading the buzz and fomenting ecosystem growth.

That said, I think what's more important is that the SC comes up with a strategic vision for the next couple of years. If that includes a better story for NixOS on the desktop I'll be pretty happy, but I don't think it's the only good such vision (vs e.g. a primary focus on NixOS as a server distribution)

@jtojnar
Copy link
Member

jtojnar commented Oct 7, 2024

I would not mind one but I would leave that up to community.

The main challenge I see is a long term maintainability and ensuring sufficient quality. I would like to see Nixpkgs only include core primitives and let the modules for programs more complex than basic RFC 42 settings be handled by external projects.

@nyabinary
Copy link
Contributor Author

I think it should and would advocate for creating a Home Management team to tackle these issues and set recommendations on what the best path forward on having a home management tool, whether that integrating it directly into Nix (which I, personally, think is the right approach), or not.

@NixOS NixOS locked as resolved and limited conversation to collaborators Oct 7, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

10 participants