I had similar problems with GNU Stow, but switched to Nix and Home Manager instead.
I think Chezmoi's templates and file naming conventions don't click for me, but it's nice to see a good variety in this problem space.
I think Chezmoi's templates and file naming conventions don't click for me, but it's nice to see a good variety in this problem space.
One major benefit for me is that I no longer need to have once-in-a-while tools installed, because I can always spin up a temporary shell with `nix-shell -p packageName`. This significantly decreased the amount of software I have in my environment.
This works great with agentic coding. Agent wants to run `ripgrep`, but you don't have it? Tell it to run `nix run nixpkgs#ripgrep` instead.
But the biggest benefit is that now that you know Nix! So you can start using it to create reproducible development environments and uninstall mise, asdf, nvm, pyenv, etc. You can spin up reproducible servers running NixOS and never touch Ansible again. You can even install it in your router.
Or you can do none of that and continue just using it for your dotfiles. It plays nice with other tools.
About 6 weeks ago I installed NixOS on a spare laptop and did 100% of the configuration through Claude Codex. Initially I copied "/etc/nixos" off to my existing workstation, until Claude Code bootstrapped it enough to run on the NixOS machine.
I've been running it as my primary workstation for the last 3-4 weeks, and it's been great! 100% configured by Claude Code or Codex CLI.
Configuring a machine via Nix lang is not that fun. Configuring a machine via English is.
And I've thrown some curveballs at this setup. I asked it for gitbutler-cli, which NixOS doesn't/didn't provide, and it was able to package up and build it. It's running Sway. I have my secrets and configs in SOPS+Home Manager.
That's the great thing about nix, it should actually compile LESS than other distros, because, you can have multiple versions of the same lib on the same machine. You just create another version of the package and only patch the packages that need it. You don't even have this option on other distros. Name one other distro that lets you run multiple versions of glibc natively (not containers or flatpaks or whatever).
The package dependencies aren't based on whether what's packaged is a linked library, and built packages are linked to the dependencies by the digests. The digest of a package is made from the store derivation which contains the digests of the dependencies. Or does the digest of a package not depend on the digests of its dependencies anymore?
Because if they do, then on changing any minor thing, like a typo on a manpage, it would cause the change to cascade by changing the digests of its own package and its dependants recursively. Meaning, none would be found prebuilt and would need to be recompiled.
EDIT: s/hashes/digests/ because that's what appears to be the conventional name for the base32 strings used to identify an entry in /nix/store. The site has changed a lot in the last decade, but I do see this in the thesis that confirms what I remembered:
> The store derivation in /nix/store/1ja1w63wbk5q...-hello-2.1.1.drv is shown in Figure 2.13. It lists all information necessary to build the component, with references to the store derivations of dependencies [...] The output field specifies the path that will be built by this derivation, if and when it is built. It is computed essentially by hashing the store derivation with the output field cleared. --- https://edolstra.github.io/pubs/phd-thesis.pdf
EDIT 2:
> I modify udev rules and the system rebuilds in seconds.
Maybe there's a beaten path for udev rules, a way to override them without modifying the package / store derivation. Or maybe the derivations you're modifying don't have many dependants.
I mean, generally when you patch things, you want all dependents to use the patched version. It's just irksome that you know the change you made strictly speaking doesn't need a rebuild of dependents, but nix will still require it in the interest of ensuring reproducibility. Just wish there were an established expert-mode I-know-this-may-break-things way to have a modified derivation act as a drop-in replacement of a particular package/digest.
For example, it would be neat to have derivation foo.nix, from which the digest is calculated. Then, have the system check for a mod/foo.nix or similar path which would be a function that can modify the derivation without having the digest be recalculated on the result. Or maybe this could be done by having a function calcDigest, which sets the digest of a derivation and the system can simply not set the field when it's already been set. This to allow further changes while being treated as if changes haven't been made.
And in return one gets a saner programming language than the Nix language.
I like mise, but at the end of the day some programs are more complex than just pulling a precompiled, dynamically linked binary and hoping it works.
I thought it was the former but "just pulling a precompiled, dynamically linked binary and hoping it works" makes me think we're not on the same page since to me that has nothing to do with dotfiles.
Also noting that I don't see the problem as "dotfile management" but as "system AND user configuration management" which extends beyond some plain text files in $HOME.
ed.: and home manager is just one tool which provides not only dotfile management, but drvs for installing particular programs and configuring then in highly opinionated ways -- I do not use it
This is a serious problem in Nix too. I often trip over buggy and abandoned Nix packages. Nix often makes it easy to roll back or work around them, but they're absolutely there.
Are you really in this thread to talk about dotfile managers, or are you here to criticize Nix, given that Nix directly competes with your company's only product?
tfrancisl was polite (even though I arguably wasn’t in the beginning) so I felt it important to return the favor.
It's also a massive pain the ass to work with
* Permission management, so that ssh wouldn't refuse to log you in because ~/.ssh/authorized_keys is 0755 instead of 0644.
* Templating, because ~/.ssh/config has slightly different options on Mac and Linux, so you can't use the exact same file contents as-is on both systems.
I can run `chezmoi apply` and get all the files in the right places and they're all setup just right. Like so many others, I'd previously built my own ad-hoc system to handle these things, and it ended up looking like a crappy, half-baked version of Chezmoi. When it came up on my radar I immediately ported my own system over to it and never looked back.
My ssh config has actual domain names of servers I don't want to publish to the whole internet so that file is encrypted on my public github dotfiles repo.
Chezmoi automatically decrypts it on `chezmoi update` and I don't need to think about it much unless I'm editing it.
For a System administrator the problem is many orders of magnitude worse
I don't understand what makes it more understandable than Home Manager, though.
If you look at the source of a Home Manager `programs.foo` module, it should look mostly like this:
home.packages = [ cfg.package ];
xdg.configFile."foo/config.yaml".source = yamlFormat.generate "config.yaml" cfg.settings;
With some programs it is as simple as you show, but with others there are options around the config and other nix module nasties that I avoid if I can. hjem-rum is a sister project to hjem that provides some similar modules.
Thanks for the recommendation.