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.
Is there an easy way to learn this for just the package manager? Most of the tutorials I find are tailored to NixOS, which I’m not using and don’t plan on using.
You can absolutely use nix and home-manager without NixOS, you can even use it on a Mac!
Most of the tutorials I find are tailored to NixOS
I think that’s less true than you think. There’s definitely a lot of tutorials from people who do use NixOS… But this mostly doesn’t matter, using nix is more or less the same regardless of operating system. There is some stuff specific to NixOS, but that’s mostly just using nix to configure system services.
Is there an easy way to learn this for just the package manager?
That said… There’s not a super easy gateway to learning nix, unfortunately. The easiest way to learn is probably to try to package one of your personal projects, or by learning home-manager and trying to fully declare your home environment. Packaging programs in certain languages can involve having to learn more about the nix ecosystem than others (e.g., python is a little more complicated than what you’d need to package a simple C program, because python has it’s own ecosystem that you have to integrate with).
Probably the best introduction is the nix pills if you want to learn how nix works (not necessarily how to use it, but it will give you a really solid foundation):
Though, it’s really common for people to bounce off of the nix pills because they start kind of slow. If you can follow through them, though, you’ll have a good understanding of the nix language and how it’s used to construct derivations for building packages.
The nix language is much maligned, but it’s actually not as bad as you think going in (error messages can be ATROCIOUS, however). It looks a bit weird, but I think if you go in with the understanding that it’s “Turing Complete JSON” you’ll have a better time. Almost everything you’re doing in nix is building up attribute sets (which are basically just JSON dictionaries) which specify the dependencies and build stages of a project… But it’s not a static representation like JSON, you can call functions to do arbitrary computations to build up fields (e.g., I have some functions to automatically set up wireguard configurations from a description of the network layout of my machines, so it’s useful to be able to do this stuff).
For what it’s worth, I don’t understand the nix language or all the package manager functions in their entirety. I generally use what I need and that’s it. Most information I’ve required that is nixpkgs-specific I was able to find in the manual. home-manager has one as well and it’s been the best reference for me.
Nix and Home Manager have been my go-to for managing dotfiles and symlinks in my home dir
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.
Is there an easy way to learn this for just the package manager? Most of the tutorials I find are tailored to NixOS, which I’m not using and don’t plan on using.
You can absolutely use nix and home-manager without NixOS, you can even use it on a Mac!
I think that’s less true than you think. There’s definitely a lot of tutorials from people who do use NixOS… But this mostly doesn’t matter, using nix is more or less the same regardless of operating system. There is some stuff specific to NixOS, but that’s mostly just using nix to configure system services.
That said… There’s not a super easy gateway to learning nix, unfortunately. The easiest way to learn is probably to try to package one of your personal projects, or by learning home-manager and trying to fully declare your home environment. Packaging programs in certain languages can involve having to learn more about the nix ecosystem than others (e.g., python is a little more complicated than what you’d need to package a simple C program, because python has it’s own ecosystem that you have to integrate with).
Probably the best introduction is the nix pills if you want to learn how nix works (not necessarily how to use it, but it will give you a really solid foundation):
https://nixos.org/guides/nix-pills/
Though, it’s really common for people to bounce off of the nix pills because they start kind of slow. If you can follow through them, though, you’ll have a good understanding of the nix language and how it’s used to construct derivations for building packages.
The nix language is much maligned, but it’s actually not as bad as you think going in (error messages can be ATROCIOUS, however). It looks a bit weird, but I think if you go in with the understanding that it’s “Turing Complete JSON” you’ll have a better time. Almost everything you’re doing in nix is building up attribute sets (which are basically just JSON dictionaries) which specify the dependencies and build stages of a project… But it’s not a static representation like JSON, you can call functions to do arbitrary computations to build up fields (e.g., I have some functions to automatically set up wireguard configurations from a description of the network layout of my machines, so it’s useful to be able to do this stuff).
For what it’s worth, I don’t understand the nix language or all the package manager functions in their entirety. I generally use what I need and that’s it. Most information I’ve required that is
nixpkgs-specific I was able to find in the manual. home-manager has one as well and it’s been the best reference for me.