[RFC 0182] I'm Gonna Build My Own Home Tool With Blackjack and Modules! #182
Conversation
Start date coauthor nyanbinary
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: |
Co-authored-by: Niko Cantero <97130632+nyabinary@users.noreply.github.com>
|
So it'd be easier to rewrite from scratch than to bring home manager into the nixpkgs tree? You say you see this competing with home manager, but we know defaults are king, and I fail to see how home manager would get new users if similar functionality is implemented in nixpkgs/nixos itself. |
rfcs/0182-user-management.md
Outdated
| - Promote an alternative toolset. | ||
|
|
||
| The most viable alternative in this field is home-manager. However it is not | ||
| so easy to assimilate a consolidated project within another consolidated | ||
| project, not only in terms of source code, but also in terms of community and | ||
| decision-making. | ||
|
|
||
| A better approach would be promote some form of a healthy competition, in | ||
| which home-manager and hometool are different projects competing for the same | ||
| niche, each with their own teams, communities, design projects etc.; further, | ||
| both teams are free to share code between them, provided they follow their | ||
| corresponding licenses in doing so. |
There was a problem hiding this comment.
I don't think this point is well made. You just say it's not easy, without elaborating on why. IMO creating this from scratch is substantially less easy, but that's not the point. You just go on to talk about competition rather than explaining what's hard about bringing in home-manager and how starting from scratch is easier.
| @@ -0,0 +1,306 @@ | |||
| --- | |||
There was a problem hiding this comment.
In order to keep the conversation more discoverable, I am copying and answering here:
So it'd be easier to rewrite from scratch than to bring home manager into the nixpkgs tree?
Not necessarily. The code does not need to be written ex nihilo.
In the worst case, ignoring all considerations over ethics, we could just merge the current state of home-manager and start working right now.
But I feel this is not correct.
You say you see this competing with home manager, but we know defaults are king, and I fail to see how home manager would get new users if similar functionality is implemented in nixpkgs/nixos itself.
Assimilate HM would be veryi nice.
Indeed I kept the previous proposal for assimilation here, but preliminary conversations on Discourse and Matrix led me to cogitate this approach.
There was a problem hiding this comment.
I definitely agree that everything does not need a rewrite, but I'd also like to highlight that many home-manager modules duplicate functionality that already exists in NixOS in some form (activation logic, systemd units, programs.* services.*). Large scale cleanup is going to be required to have a smooth transition that doesn't break in little places everywhere.
|
In order to keep the conversation more discoverable, please refer to the lines of the file itself (the first one in case of general remarks). |
There was a problem hiding this comment.
As a preface: this is my first time reviewing an RFC, so apologies for anything inconsistent with what would usually be included in these. I also haven't had my morning coffee yet :(
Overall, I'm very happy to see this submitted. home-manager has been one of my favorite parts of the Nix ecosystem since I first got into it, and I think bringing that under nixpkgs (and the wider NixOS org) would help a lot in both new users picking it up, as well as bettering the experience for existing ones
This RFC in it's current state feels very incomplete, however. Most of the "detailed design" is very vague and does not begin to describe how things would be implemented; it feels more like a list of goals rather than anything we can base work off of. I would be concerned about these omissions causing a lot of bikeshedding once work begins, even with a merged RFC. A lot of work (and discussion) will need to go into this in order for us to find a useful, but realistic and maintainable architecture for this system IMO. #140 and #166 are good examples of explicitly describing an implementation like this
Another aspect I think is missing (but wasn't sure where to really put) is how this would interact with NixOS itself. home-manager currently does this through a system module that allows the user to manage both the system and basic user(s) under one closure, which can be quite useful in avoiding desyncs between both configurations, as well as not forcing the user into running two commands like nixos-rebuild switch --upgrade and hometool upgrade
rfcs/0182-user-management.md
Outdated
| Users can extend the module set by writing their own, leveraged by overlay and | ||
| other Nix language constructs. |
There was a problem hiding this comment.
I feel this is a bit vague. Writing your own modules and importing them is of course a mainstay in the NixOS module system -- but I'm not sure how overlays and "other Nix language constructs" would fit here. Is this referring to the customization of packages used by a module in an overlay rather than extending the module itself? What language constructs would assist in extending an existing module for example?
| `hometool` should be scalable from the simplest to the more complex user | ||
| environment definitions. |
|
|
||
| - Documentation | ||
|
|
||
| Both the `hometool` and the moduleset should be well documented. |
There was a problem hiding this comment.
We should be more specific as to what "well documented" means. Should this have a dedicated manual similar to nixpkgs/NixOS? What about support for these modules on search.nixos.org?
| This `hometool` should be approachable with clear and understandable logging | ||
| messages, plus the aforementioned documentation. |
There was a problem hiding this comment.
This should probably also include the UX of the tool, as documentation and logging is really only one step in being "user friendly" (especially in the context of the CLI)
| What? Lisp is cool! | ||
|
|
||
| # Prior art | ||
| [prior-art]: #prior-art |
There was a problem hiding this comment.
I would like to see nixos-rebuild in this section as well, as even though it is meant for system wide configurations, it is a good example of a tool meant to build, deploy, and test Nix profiles. Its CLI should also be taken into account when designing hometool here as it's what most Nix users will be familiar with -- home-manager is also (seemingly) inspired by it, for example
| ## Wrapper Manager | ||
|
|
||
| Wrapper-manager is a Nix library that allows the user to configure your favorite | ||
| applications without adding files into `~/.config`. This is done by creating | ||
| wrapper scripts that set the appropriate environment set - variables, flags, | ||
| configuration files etc. - to the wrapped program. |
There was a problem hiding this comment.
While this is prior art, I am a bit confusion by its inclusion. Is this implying the modules should take inspiration from this as opposed to using mkOutOfStoreSymlink as home-manager does?
Also linking the author's blogpost on replacing home-manager with this, as the project is relatively new and the post gives some background to readers who are unfamiliar (like I was until a few days ago :p)
rfcs/0182-user-management.md
Outdated
| - Set expectations on portability among present and future platforms Nixpkgs | ||
| supports | ||
| - Especially outside NixOS | ||
| - Especially outside Linux |
There was a problem hiding this comment.
I feel this is a bit out of scope for this RFC. Expanding platform support in nixpkgs is important of course, but I don't think it has much to do with user management
There was a problem hiding this comment.
I disagree. Home management would be a part of the package manager, not NixOS. I don't see why derivations would work on other systems but home management won't, it feels like a regression to me.
Also, #163 should pave way for the implementation of things detailed in this RFC if/when accepted, making support for other platforms not so out of scope, IMO.
There was a problem hiding this comment.
Home management would be a part of the package manager, not NixOS. I don't see why derivations would work on other systems but home management won't, it feels like a regression to me.
My interpretation of this was moreso that it was encouraging better support for platforms in derivations, not this tool specifically. If this is speaking about hometool, I'm still not sure why it would be considered "future work". Portability should be considered from the beginning here, as frankly there isn't much reason to make most modules platform specific; for example in home-manager, a vast majority of modules are already only limited by the package's platform support
If I was correct in my initial reading though, I think my point still stands. Allowing derivations to build for more targets doesn't have much to do with introducing ways to configure them
There was a problem hiding this comment.
Well, if you're correct on that, then nixpkgs already supports more targets even if not formally listed in some policy.
If it's regarding hometool, then yes it should be done from the get-go and not defer it for later.
There was a problem hiding this comment.
Well, in my experience different distros do not share /home well.
There was a problem hiding this comment.
Well, in my experience different distros do not share /home well.
I'm a bit confused what this has to do with the current thread. I don't believe sharing /home was mentioned anywhere
There was a problem hiding this comment.
I think the wording here is ambiguous. @AndersonTorres by "platform" do you mean architectures or OS/distributions
There was a problem hiding this comment.
I'm a bit confused what this has to do with the current thread. I don't believe sharing
/homewas mentioned anywhere
Anecdotal evidence ahead.
In the old times I was switching from Slackware to Arch, my /home lived in a separate partition.
When I installed a second distro, the programs in the second distro did not recognize what was already present in the /home. The distros did not share /home well.
I this the wording here is ambiguous. @AndersonTorres by "platform" do you mean architectures or OS/distributions
Operating system - and everything it implies but we usually abstract away (libc, userland etc.).
There was a problem hiding this comment.
In the old times I was switching from Slackware to Arch, my /home lived in a separate partition.
When I installed a second distro, the programs in the second distro did not recognize what was already present in the /home. The distros did not share /home well.
I'm well aware of these types of issues, but again I'm not sure what it has to do with the current thread. Are you implying this tool should act similar to sharing a /home but not have the typical issues associated with it?
Operating system - and everything it implies but we usually abstract away (libc, userland etc.).
This needs to be specified in the RFC. The current wording is (once again) vague
|
|
||
| - Customizability | ||
|
|
||
| Users can derive specialized module configurations from current module set. |
There was a problem hiding this comment.
This is very similar to the next point. How would a user go about this?
There was a problem hiding this comment.
Exempli gratia, the user should be able to override the emacs program from a programs.emacs module.
(This is a recent concern in NixOS modules; many of them hardcode the main program.)
There was a problem hiding this comment.
That doesn't sound much like a "specialized module configuration" to me, just ensuring support for what should be basic options in a module. The wording here implies extending/editing the base modules to fit individual needs; simply introducing a package option fails to do this IMO
There was a problem hiding this comment.
The wording here implies extending/editing the base modules to fit individual needs
This would be interesting too.
There was a problem hiding this comment.
That'd be awesome even in NixOS honestly, it'd be nice to have a slightly nicer interface to extend modules, particularly the ones that use submodule types (sure its not hard, but it could be made simpler maybe)
|
This proposal basically boils down to “we should rewrite Home Manager in Nixpkgs, but better”. How it should be better is not elaborated upon; there are plenty of gripes you could have with Home Manager in terms of maintenance state, basic concepts ( The advantage of Home Manager is that it actually exists. If its maintainers were interested in moving it into Nixpkgs, and the Nixpkgs community was amenable to that, then the path forward would be clear and there would be relatively few design decisions to be made. “Let’s just write our own thing” is not a viable proposal without significantly more detail about what our own thing should actually be. I think that if you want a from‐scratch home management tool integrated into Nixpkgs, the best approach would be to prototype it out‐of‐tree and then open an RFC proposing its inclusion in the Nixpkgs repository; that way we could have a discussion about its design decisions and implementation trade‐offs. As it is, this RFC is a very bare‐bones sketch that punts on all the difficult problems and has no clear commitment to being implemented if accepted. I’m not sure it will be productive for the project to discuss it in its current state. |
infinisil
added
the
status: open for nominations
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/rfcsc-meeting-2024-09-30/53690/1 |
|
RFCSC: This RFC needs shepherds move forwards. Whether the final decision is to accept or reject the RFC the shepherd team is critical for ensuring that all viewpoints are considered and that the RFC doc answers any questions. Please consider nominating yourself or others as shepherds so that we can move this RFC towards conclusion. |
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/rfcsc-meeting-2024-10-28/55095/1 |
|
Given that the original developer of Home Manager agrees with assimilating HM, I want to reformulate a truckload of things. So I will draft this. |
| prototype and test ideas, older and newer. | ||
|
|
||
| # Prior art | ||
| [prior-art]: #prior-art |
There was a problem hiding this comment.
I believe NixOS/nixpkgs#9250 really deserves a mention here. FWICT it is the closest thing to what is proposed in this RFC.
| - Especially outside NixOS | ||
| - Especially outside Linux |
There was a problem hiding this comment.
I think both of these points are going to become a real burden for future use, and I'd honestly somewhat discourage their practical application. home-manager already somewhat suffers from this "one shoe fits all" philosophy by duplicating NixOS module logic all over. Of course, for home-manager specifically this is not a problem, because they never aimed to be a NixOS only tool anyways, but if we are going to bring in first class support, we have to decide to what extent are we willing to duplicate and re-use modules from NixOS if we want to consider support for a broader ecosystem. It's not like NixOS modules can be used outside of NixOS (future RFC pending?) and the guarantees we can make in an environment outside of the module system is slim at best. It would also be practically unfeasible to attempt what home-manager does and reinvent the wheel everywhere, because that leads to duplicated logic and maintenance burden.
To be completely fair, I actually would love the idea of a world where I could declare any Linux system OOTB using Nix/NixOS modules and make it work, and optionally declare a home environment in much the same way, but practically those are hard to implement, especially at our level. The most I think we should ever realistically aim for is first-class support for NixOS only. Tighter integration allows us more flexibility in what we can re-use, more testing and applicable user experience to improve the tooling from, and although not necessarily the strongest point: makes NixOS a more appealing distribution for reasons beyond just system level configuration.
There was a problem hiding this comment.
If support for the non‐NixOS Home Manager platforms is dropped, then this will not result in merging Home Manager into the Nixpkgs monorepo or usurping Home Manager by something better; it will just result in an ecosystem fracturing between the home management tooling in the Nixpkgs monorepo and the Home Manager that will continue to exist. It is very popular to use Home Manager to manage user environments on non‐NixOS Linux and macOS, and a significant new user funnel for NixOS – besides which, the utility of Home Manager is decreased if it has to be integrated into a monolithic NixOS configuration and doesn’t allow individual users autonomy anyway, as it makes the multi‐user case a pain, and the single‐user case is already served fairly decently by NixOS already.
This RFC proposes to enhance Nixpkgs monorepo with a declarative management system for basic users.
Co-authored by me and @nyabinary
Rendered!