IMO rearchitecture would be cleaner, since we already have an RFC considered to do exactly that (the “portable services” idea) and we don’t have to inherit 7 years of bad design and duplication on top of what we already need to work on nixpkgs.
(And if we can actually get the portable services idea through, we don’t need to take any inspiration from HM in the first place, it’s essentially just a new project.)
Yeah, pretty much. 100% agree here.
Actually, has anyone considered a systemd.tmpfiles hm-like system?
systemd.tmpfiles can take a file, any file, and link it to any location that you might want to have it in. The same concept of passing a nix snippet to a writer (toYAML or anything else) in combination to builtins.toFile would do the same thing as home-manager but without the cursed activation script stuff and using systemd services proper.
Slightly offtopic: There should be a NixOS Matrix room discussing this.
We can either work our way up to match HM while taking inspiration from it, or work our way down by chipping away at HM imperfections that we want to remove. Either way we will hurt the end user experience as Fernando mentioned – which, IMO, is worth it.
The HM DAG is sweet. It would be nice to be able to express dependency/ordering relations for things that get ‘compiled down’ to shell scripts or other flat files in NixOS like we can do in Home Manager. I’d like to see that make its way into NixOS one way or another.
Better yet, there should be an RFC discussing this xD
Thanks for reminding. This is definitely a feature that I really like about HM and would love to see it in nixpkgs, however implemented.
wow, too much replies
Meditating a bit, I am more inclined to the nyanbinary approach here, namely, creating our own HM with blackjack and Nix Modules.
However, there are many good ideas that I want to see implemented, e.g. the HM DAG functions from their lib: home-manager/modules/lib at master · nix-community/home-manager · GitHub
Further, I think we should somehow honor the know-how, both as an example to be followed (dag) and as a lesson to be learned (mkOutOfStore…).
What do you think of the tmpfiles idea btw?
Looks nice.
I would be slightly against because it is too systemd-esque, but the idea behind it is useful and easily generalizable.
i assume home-manager remove symlinks when you remove a file from your configuration, right? if so, how would you propose handling that with your approach?
I mean NixOS is already a very systemd-esque distro it relies on it a lot so that doesn’t really matter imo.
tmpfiles alone cannot currently handle that.
If only we had something that can handle removed entries already in nixos, like environment.etc 
tmpfiles are automatically cleaned, I believe that includes symlinks as well, so practically same way HM handles it now (but correct me if I’m wrong anyone :3)
Mind that one central value proposition of HM is that it also works on Darwin. I see it as part of the funnel to growing user commitment:
Unless we’d ship such a thing with systemd somehow, that won’t really fly.
@nyanbinary i don’t believe your statement to be true
if you include a cleanup-age argument then directory like objects (not files or symlinks) can automatically be deleted from the filesystem after a certain period of time… but you don’t want the items specified by tmpfiles to be removed, so that doesn’t count
back to the point i had though… if you remove something from your configuration then an entry will no longer exist in tmpfiles so even if tmpfiles could remove it, which it cannot, the entry would no longer exist in tmpfiles so it wouldn’t be cleaned up
yeah! environment.etc handles this scenario well and would be a good model to use as it doesn’t rely on anything exotic (ie. it is portable and works without os configuration)
I am highly skeptical anyone is going to be motivated to write a replacement from scratch in-tree. Feel free to prove me wrong, but I think merge then refactor is a much more likely outcome.
Looking at this from the perspective of an RFC, I think that architecture decisions’ dependence on the relative difficulty of implementation should be minimal.
While I hate to say that you’re likely right, I hope that doesn’t turn out to be the case, at least not because the alternative was too difficult to do.
That’s what I keep trying to say.
I really do not believe there is a need to do this “from scratch”, we have nearly everything to get started in tree, only that we want to come up with a scheme to make modules less coupled to nixos (which would be great anyway, because this brings us the ability to do, for example, system-level config outside of nixos). That’s less “from scratch” and more “let’s figure out what needs refactored”.
That’s great… for HM. What NixOS needs is user-level config management, not HM.
I don’t consider the needs of nix-darwin to be a priority here.
Home Manager devs, from what I tell aren’t interested in that.
Furthermore, if we do refactor HM, the refactoring would still break like all users of hm config right now. It would practically be the same result of the end user having to manually update their config to unbork their config.
tmpfiles can write files to anywhere and environment.etc can only well write to /etc.