[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 <[email protected]>
|
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.
|
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.
|
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.
This RFC proposes to enhance Nixpkgs monorepo with a declarative management system for basic users.
Co-authored by me and @nyabinary
Rendered!