You can manage symlinks pretty easy with home-manager. I'd personally setup symlinks for these app configuration directories if I don't want them storing files directly on the disk I use for $HOME. It's also done in a delcarative way that can persist across multiple computers.
I'm not sure I understand. So you create a symlink from $HOME/.program.ini to something in the nix store? If so, how does that solve the problem of clutter in $HOME ?
If so, how does that solve the problem of clutter in $HOME ?
If it wasn't clear from my message, the problem(s) these tools are solving for me would be 1. not having to keep track of my dotfiles and their directories, and 2. not storing configuration files directly on the disk I use for the $HOME dir. I'm not claiming these tools would solve clutter in the $HOME dir. Further, I think it should be alright for me to share tools for managing configuration files in your home directory in a discussion that directly relates to that subject.
So you create a symlink from $HOME/.program.ini to something in the nix store?
Normally it's the other way around. When you use nix and home-manager, you're technically generating files that will live in the nix-store and nix/home-manager will take care of symlinking those files to locations in your $HOME dir.
My particular use-case is that I want persistent configuration files that are shared throughout a handful of devices on my network. To this end, I use some home-manager symlinks that lead to a network folder where all these various directories and configuration files actually live. I edit those configurations in a single place and their changes propagate across the network to all the devices that would use them.
You're right, it doesn't. That does give me an idea though.
You could use overlayfs with an opaque upper directory to hide the files littering your $HOME and still access them by bind-mounting them into the appropriate xdg dirs.
If a program just uses
$HOMEor someone starts writing a new application, how is that supposed to help?You can manage symlinks pretty easy with home-manager. I'd personally setup symlinks for these app configuration directories if I don't want them storing files directly on the disk I use for
$HOME. It's also done in a delcarative way that can persist across multiple computers.I'm not sure I understand. So you create a symlink from
$HOME/.program.inito something in the nix store? If so, how does that solve the problem of clutter in$HOME?If it wasn't clear from my message, the problem(s) these tools are solving for me would be 1. not having to keep track of my dotfiles and their directories, and 2. not storing configuration files directly on the disk I use for the
$HOMEdir. I'm not claiming these tools would solve clutter in the$HOMEdir. Further, I think it should be alright for me to share tools for managing configuration files in your home directory in a discussion that directly relates to that subject.Normally it's the other way around. When you use nix and home-manager, you're technically generating files that will live in the nix-store and nix/home-manager will take care of symlinking those files to locations in your
$HOMEdir.In this scenario though, I would use the https://nix-community.github.io/home-manager/options.html#opt-home.file option from home-manager to create a symlinks to a location that's outside of my
$HOMEdir so those files don't have to live on my home disk.My particular use-case is that I want persistent configuration files that are shared throughout a handful of devices on my network. To this end, I use some home-manager symlinks that lead to a network folder where all these various directories and configuration files actually live. I edit those configurations in a single place and their changes propagate across the network to all the devices that would use them.
You're right, it doesn't. That does give me an idea though.
You could use overlayfs with an opaque upper directory to hide the files littering your $HOME and still access them by bind-mounting them into the appropriate xdg dirs.
Way more effort than it's worth, of course.