right, which is why we wouldn’t use environment.etc - but we could use something like it
i am still not clear on what you are proposing to do for cleanup with tmpfiles, though
i mention because i have used the user level tmpfiles for doing exactly what you’re proposing here and as long as you never want to cleanup any files it is fine… i found limitations when removing configuration though, as the links/files aren’t cleaned up
Indeed, managing user-level symlinks would require a proxy symlink in some “well-known” directory.
For example, pointing .gitconfig → .some/well-known/gitconfig → /nix/store/...
That way, if with an update, you remove .some/well-known/gitconfig, then .gitconfig gracefully becomes a dead symlink.
On another note, I don’t know if tmpfiles is the approach here. For what is worth, it would serve glorified approach to a list of calls to cp/ln. And you would be removing support for macos (!!) and container targets, or even some exotic usecases as activating inside a derivation.
In the end, there are different things that HM does:
Which could be pulled apart, even as a non-nix project, with a Nix abstraction on top. stow-manager maybe?
Being able to say
environment.home.matklad.".config".bat.config = ''
--theme=GitHub
'';
would significantly simply my personal configuration, yeah.
I don’t understand why environment.etc is restricted to, well, /etc, feels like a needless restriction.
One of the things NixOS needs, along with the Nix ecosystem as a whole, is a kind of continuity and cohesion. If NixOS gains a feature that HM makes redundant on NixOS itself but couldn’t even hope to replace it, it’s going to add to the copy/paste mess of the proliferation of module systems that we have now. It’s confusing for users and it’s lots of duplicated effort.
Guix already gets this right… guix home is a part of Guix and it also works on other distros.
I’d like to add that as a long time NixOS user, the configuration management capabilities of HM are not really what makes it valuable for me. I started using HM only because it offered a way for my software management and service management to be directly shared across operating systems in a declarative way. There are lots of great dotfile management strategies outside of the Nix world, Nixpkgs-only-based wrappers are great and available for most of the applications where my configs are actually very complicated, and lots of non-developer applications frankly do fine without config management. One of rhe main advantages of doing this kind of configuration at the user level is that Nix doesn’t have to own the whole system to do user-level stuff— and so the system doesn’t have to be NixOS.
Also HM’s usefulness on Darwin doesn’t really have anything to do with Nix-Darwin. You can use them together or not. The reason that HM working on non-NixOS is important is that it gives users a way to leverage Nix for declarative software, configuration, and service management in environments where they can’t or don’t want to commit to having Nix run the whole OS, and in a way that they can reuse if/when they do come to NixOS. It’s not because HM makes Nix-Darwin better, and it would apply just as much if we were talking only about foreign Linux and not also Darwin.
I don’t think NixOS needs to concern itself with what nix-darwin, hm, etc. do, that’s what I’m getting at.
If HM has its own impl that works in multiple scenarios, great! But we don’t need to adopt it in NixOS. NixOS should support NixOS first and foremost, not be forced into a design based on what HM or nix-darwin needs. Of course it’s not a bad thing if other projects can benefit from what NixOS does, but that’s a different scenario from “NixOS must maintain compat with every other OS in the world”, that’s backwards and unnecessarily onerous.
From what I’ve seen, agreed. What I see here is a classic example of competing standards. I think a solution does exist here – but unfortunately not in the short term.
The issue at hand: NixOS has many external tools that many users rely on. These include:
Several of these are controversial, some for good reason. For the purposes of this conversation, let’s examime home-manager.
In an ideal world, home-manager would be perfect on a technical scale, the maintainers would be in favor of merging it into NixOS, and it would be an easy merge. None of these appear to be true.
Unfortunately, unless these all magically changed suddenly, I don’t think the merging of home-manager will happen. We have to accept that any solution will require some reinvention of the wheel.
With this in mind, I think it has to be acknowledged that this will not be a fast process. RFC 163 still remains somewhat stagnant. Perhaps progress will suddenly appear, but I think it can’t be expected. In several years, we may still having the same discussions. Maybe these discussions need to happen: there’s many examples in the history of Nix where a rushed development cycle led to a lot of issues. But I think waiting around forever can be just as bad.
I’d advocate for systems to be put in place for facilitating these discussions. This can be an RFC, a matrix channel, a timeline for prototyping, etc. The best way to make progress is to create systems that help to facilitate that progress.
Like Home Manager merging, refactoring is dead if HM maintainers don’t want that. I think building a solution from scratch is way better.
If we’re no longer discussing the integration of home-manager, as this discussion post is named, it could be valuable to move this to another location.
One thing I want to address is why I think we should be having these discussions, and why integration of external projects is valid. Many of my issues with home-manager as a user are related to reliance on external systems. Nix and its ecosystem, for all its faults, has many systems in place when it comes to RFCs, PRs, security, etc. We could argue about the implementation of these systems (see the recent 2.24 security patch for your unhealthy dose of discourse). But these systems do exist.
On external projects, there is no guarantee of such systems.
@viperml has discussed this in the lens of security here, but I think there’s an important side when it comes to usability. There’s some amount of sanity checks when it comes to NixOS and its features. If something in NixOS is frustrating me, I can make an issue or PR, and expect that it’ll at least receive some attention. But an external project makes no such guarantees. Many of my gripes with home-manager are solved in existing PRs, but they’ve remained stagnant.
If a project is being heavily used by NixOS users, yet its systems are holding it back, I think the best solution is to reinvent the wheel: fulfill the same need as the external project, with the NixOS systems helping to support its ongoing development.
I guess there is a large difference of opinion here depending on whether you think of the end‐goal as “add user environment management modules and tooling to the Nixpkgs monorepo” or “add user environment management as a NixOS feature”. This is not just about macOS (and Home Manager on macOS is distinct from nix-darwin, FWIW), but also about users on other Linux distributions. (Both of those end up being a big NixOS new user funnel in my experience, for what it’s worth.)
I made a matrix room to discuss this more in depth if anyone wants to join. :3
#nixos-hm-rfc:nyanbinary.rs
Unsure if I agree here. It’s a good reminder that we’re talking about nixpkgs here, not NixOS, which is supported across many distros, macos, and wsl. I don’t see why a home management module would be restricted to just supporting NixOS when the packages aren’t (edit: more or less what @emily mentioned later in the thread). Loosely related but the point of RFC 163 is to allow having some limited support for operating systems supported by Nix.
The refactorings don’t necessarily have to be done in HM, or its default branch. It can just be forked off, refactored, and then merge the fork into nixpkgs. I don’t mean to say that we shouldn’t discuss this with HM maintainers; we should, and I think the people in this thread have made honest efforts to get in touch with them.
I disagree. “Reinventing the wheel” is an alternative of the proposed RFC in this thread, so it’s still relevant here. On that note, @AndersonTorres perhaps the RFC title could be agnostic of HM itself? I don’t mean the contents itself, that can still push for HM assimilation.
Fully agree here.
I would much prefer using either Discourse or GitHub for these discussions since they force people to slow down and type larger messages instead of a relatively spammy mess. Although I suppose a Matrix channel would be made post-RFC creation anyway?
Many other RFCs have Matrix channels, so I decide to make one too :p, once it becomes an official proposed RFC I can ask the mods to pull it in the NixOS space and just call it NixOS: RFC#xxxx or something like that, and yes, presumably the channel would be made post-RFC (we can just rename it after the RFC gets accepted)
The perl based etc module removes dead symlinks by scanning the whole /etc. This approach doesn’t work on a larger folder, e.g., /home. But I thought the new overlayfs based approach works everywhere.
I agree, it would be nice to have a way to declaratively ensure a file exist at any place of the whole system. It seems a bit weird to me that it is a key withing environment too. Maybe it could be a dedicated key like filesystem or idk. I’m also split between having a attribute set structure, like you showcased home.${user}.config.[...] = something or a flat list of attribute set with { fullpath = "..."; text = something; } (the latter could also provide other settings, maybe?)
limiting the scope to ~/.config and maybe ~ (without deep recursion) would solve that problem
definitely! i was also thinking overlayfs might be a great solution, though requires os support - which may or may not be an issue depending on the scope of what happens
I don’t think limiting scope is a good idea. I rather a user have max control. :3
New link :3
I think a much simpler solution would be to create an index of sorts; a list of all files managed declaratively in a standardised format. Each generation would produce such an index. Its format could be as simple as a bunch of key-value pairs in a JSON but the details don’t really matter, what’s important is that it’s pure data.
You’d then have a generic tool which diffs the indices of the generations you’re switching between and acts out the required changes to transform the real-world state from index A to index B. (Of course it should first verify the integrity of the state against index A and add the violations to the transformation.) The time complexity of each run would be O(n) where n is the number of files managed declaratively (though you could likely easily parallelise this).
Overlayfs is quite complex to implement in an unprivileged environment and doesn’t really work for a persistent read-write use-case to my knowledge. It works great for ephemeral containers and such but I cannot imagine it working well in the context of your home directory.
After some considerations, I am proposing a from-scratch approach:
Edit: have mercy of my soul. It is now a proposal!