5 ms·

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,

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.

colordrops 4mo ago
People shy from Nix because of supposed complexity but it really is the only real solution to this sort of problem. It's not really that much more difficult to learn, and in fact if you are willing, AI works really well generating nix config.
- chungy 4mo ago
  Guix solves the same problem in similar ways, though it uses Scheme as its configuration language.
  - drdexebtjl 4mo ago
    Sadly it doesn't work on macOS, unlike Nix.
    - pkulak 4mo ago
      Or hardware.
      - sham1 4mo ago
        It absolutely works with hardware. And it's not that difficult to add channels for extra software like a tainted Linux kernel. And in return one gets a saner programming language than the Nix language.
- drdexebtjl 4mo ago
  It took me a single afternoon to learn the basics and start using it. Contrary to what I initially thought, I didn't have to migrate all of my dotfiles at once. Then over the next couple of days, Codex migrated everything else for me. 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.
- QwenGlazer9000 4mo ago
  It's not complexity its questionable documentation. Picking up Nix is really hard yet the best we got is a mishmash of unofficial recourses and many of them are out of date and/or focus on the packaging side which is terrible for introduction.
  - linsomniac 4mo ago
    I spent a year dabbling in NixOS, getting a few "toy" setups. 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.
- jorvi 4mo ago
  Nix's complexity isn't with itself, its if you try to step one bit off the beaten path where it immediately starts to grate.
  - colordrops 4mo ago
    That problem is overstated. I've been dozens of custom packages and modules and it's not that much more complex that basic Nix config, and in fact is a huge positive, not negative. How easy can you write config that packages a binary and/or sets up a new service reproducibly? I'd much rather do that on Nix than Ubuntu or Arch for sure.
    - jolmg 4mo ago
      If you modify a base package, like maybe to apply some minor patch on a systemd executable as an example, is there a way to avoid having to recompile basically all installed packages (for being at least indirect dependents)? Had a problem like that about a decade back.
      - colordrops 4mo ago
        No, it doesn't recompile everything, that's not how Nix works. The only way it would recompile everything is if, for example, you modified a particular version of glibc that was imported by most packages. Something else must have happened. I modify udev rules and the system rebuilds in seconds. 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).
        jolmg 4mo ago
        > The only way it would recompile everything is if, for example, you modified a particular version of glibc that was imported by most packages. 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 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.
- jdxcode 4mo ago
  how nix-pilled do you have to be to think that nix is the "only real solution" to dotfile managers?
  - tfrancisl 4mo ago
    Its the only complete, reproducible, and portable solution, in my opinion. 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.
    - jdxcode 4mo ago
      I am genuinely confused. Are you saying dotfile managers need to be more complex? Or that nix's problem space is the only solution for the things in nix's domain? (of which dotfiles are just one—via home manager) 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.
      - tfrancisl 4mo ago
        I'm saying that I value the completeness (thoroughness may be a better word) as well as the reproducability and portability that nix ensures over convenience. I cant tell you the amount of times I've pulled a precompiled tool and it just doesnt work because of one quirk of their packaging or another. 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
        bronson 4mo ago
        > I can't tell you the amount of times I've pulled a precompiled tool and it just doesnt work because of one quirk of their packaging or another. 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.
- arikrahman 4mo ago
  A agree, Nix is very doable. With Deepseek or other cheaper models, you could get a whole headache-free setup done in one weekend for a few cents on the dollar.
- NamlchakKhandro 4mo ago
  Nix doesn't work on windows. It's also a massive pain the ass to work with
bkummel 4mo ago
I didn't even know that managing dotfiles was a "problem space".
- awesome_dude 4mo ago
  Even just as a user of nix there has been this problem of how to manage dotfiles - people have git repositories for them but they are copies, because the actual dotfile in use is never tracked For a System administrator the problem is many orders of magnitude worse
- kstrauser 4mo ago
  It's dead simple to manage files in git or such. What Chezmoi adds over that are niceties like: * 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.
  - theshrike79 4mo ago
    Also encryption with `age`. 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.
    - kstrauser 4mo ago
      Oh, that's slick. I haven't needed to do that yet and I keep my stuff in a private repo, but see the benefits to it.
      - 4mo ago
reinitctxoffset 4mo ago
[flagged]
- tfrancisl 4mo ago
  What a snakepit of a comment! I know there are tensions within nix but this feels like a classic case of Chestertons fence at a big scale.
  - reinitctxoffset 4mo ago
    [dead]
  - charcircuit 4mo ago
    These things really do not have an actual reason. Take for example the Nic people who go to every project with a bash script that uses #!/bin/bash and tells them to use #!/usr/bin/env bash. There is no justification for trying to fix every bash script in existence over the operating system being able to resolve what the "current" bash version should be (/usr/bin/env already has to pick a version). This is pointless O(n) busy work Nix people have created for themselves when an O(1) solution exists.
    - zaik 4mo ago
      If you decide to create a package for the project in nixpkgs, patch-shebangs.sh should do it for you, no?
      - reinitctxoffset 4mo ago
        Getting a patch into `nixpkgs` is not a reasonable bar for running some program you want to try. This is an (admittedly polite) way of saying more or less "you're holding it wrong". I respectfully disagree. For expert users, creating a flake and/or standalone derivation is a little more reasonable of an ask. It is an unreasonable ask of people who are considering adopting Nix, and the friction is artificial, it serves no practical benefit (you'll notice that things like `nix-ld` are in `nix-community` now, long-time community contributors like Mic92 said a long time ago, we need to stop the bleeding on this). And once you get out of the merely alienating to anyone used to being treated well, and into actually complex software builds, "possible once you learn the incantations" goes to "never happens, you will never run this without Docker on NixOS". I won't settle for that, so I fix things: ``` b7r6 on ultraviolence ~ nix run github:sensenet-ai/nvidia-sdk#python Python 3.12.12 (main, Oct 9 2025, 11:07:00) [GCC 15.2.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import tensorrt_llm W0619 15:07:35.110000 14798 /nix/store/xgk8wcis2avy1vsv66viw150jv78v6qs-ngc-python-packages-ngc-25.12-rootfs/lib/python3.12/site-packages/torch/utils/cpp_extension.py:2422] TORCH_CUDA_ARCH_LIST is not set, all archs for visible cards are included for compilation. W0619 15:07:35.110000 14798 /nix/store/xgk8wcis2avy1vsv66viw150jv78v6qs-ngc-python-packages-ngc-25.12-rootfs/lib/python3.12/site-packages/torch/utils/cpp_extension.py:2422] If this is not desired, please set os.environ['TORCH_CUDA_ARCH_LIST'] to specific architectures. [TensorRT-LLM] TensorRT LLM version: 1.1.0 >>> import torch >>> torch.cuda.is_available() True >>> ```
tfrancisl 4mo ago
If you like home manager but also like to understand how your "home"/user programs are configured, take a look at hjem!
- drdexebtjl 4mo ago
  Last time I looked, it only worked with NixOS. 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; Which is pretty much exactly the same syntax you get with Hjem, but with more optional features. So you could just write that instead whenever you want full control :)
  - tfrancisl 4mo ago
    It works on darwin and any linux just fine. Theyre even working on a "standalone" like HMs, if you really want to decouple your user programs from your system. 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.
    - drdexebtjl 4mo ago
      I'll take a look again once it's a bit more mature. I need a standalone, single-user, rootless mode for it to work on all my systems. Thanks for the recommendation.

colordrops 4mo ago

People shy from Nix because of supposed complexity but it really is the only real solution to this sort of problem. It's not really that much more difficult to learn, and in fact if you are willing, AI works really well generating nix config.

chungy 4mo ago
Guix solves the same problem in similar ways, though it uses Scheme as its configuration language.
- drdexebtjl 4mo ago
  Sadly it doesn't work on macOS, unlike Nix.
  - pkulak 4mo ago
    Or hardware.
    - sham1 4mo ago
      It absolutely works with hardware. And it's not that difficult to add channels for extra software like a tainted Linux kernel. And in return one gets a saner programming language than the Nix language.
drdexebtjl 4mo ago
It took me a single afternoon to learn the basics and start using it. Contrary to what I initially thought, I didn't have to migrate all of my dotfiles at once. Then over the next couple of days, Codex migrated everything else for me. 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.
QwenGlazer9000 4mo ago
It's not complexity its questionable documentation. Picking up Nix is really hard yet the best we got is a mishmash of unofficial recourses and many of them are out of date and/or focus on the packaging side which is terrible for introduction.
- linsomniac 4mo ago
  I spent a year dabbling in NixOS, getting a few "toy" setups. 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.
jorvi 4mo ago
Nix's complexity isn't with itself, its if you try to step one bit off the beaten path where it immediately starts to grate.
- colordrops 4mo ago
  That problem is overstated. I've been dozens of custom packages and modules and it's not that much more complex that basic Nix config, and in fact is a huge positive, not negative. How easy can you write config that packages a binary and/or sets up a new service reproducibly? I'd much rather do that on Nix than Ubuntu or Arch for sure.
  - jolmg 4mo ago
    If you modify a base package, like maybe to apply some minor patch on a systemd executable as an example, is there a way to avoid having to recompile basically all installed packages (for being at least indirect dependents)? Had a problem like that about a decade back.
    - colordrops 4mo ago
      No, it doesn't recompile everything, that's not how Nix works. The only way it would recompile everything is if, for example, you modified a particular version of glibc that was imported by most packages. Something else must have happened. I modify udev rules and the system rebuilds in seconds. 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).
      - jolmg 4mo ago
        > The only way it would recompile everything is if, for example, you modified a particular version of glibc that was imported by most packages. 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 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.
jdxcode 4mo ago
how nix-pilled do you have to be to think that nix is the "only real solution" to dotfile managers?
- tfrancisl 4mo ago
  Its the only complete, reproducible, and portable solution, in my opinion. 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.
  - jdxcode 4mo ago
    I am genuinely confused. Are you saying dotfile managers need to be more complex? Or that nix's problem space is the only solution for the things in nix's domain? (of which dotfiles are just one—via home manager) 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.
    - tfrancisl 4mo ago
      I'm saying that I value the completeness (thoroughness may be a better word) as well as the reproducability and portability that nix ensures over convenience. I cant tell you the amount of times I've pulled a precompiled tool and it just doesnt work because of one quirk of their packaging or another. 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
      - bronson 4mo ago
        > I can't tell you the amount of times I've pulled a precompiled tool and it just doesnt work because of one quirk of their packaging or another. 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.
arikrahman 4mo ago
A agree, Nix is very doable. With Deepseek or other cheaper models, you could get a whole headache-free setup done in one weekend for a few cents on the dollar.
NamlchakKhandro 4mo ago
Nix doesn't work on windows. It's also a massive pain the ass to work with

bkummel 4mo ago

I didn't even know that managing dotfiles was a "problem space".

awesome_dude 4mo ago
Even just as a user of nix there has been this problem of how to manage dotfiles - people have git repositories for them but they are copies, because the actual dotfile in use is never tracked For a System administrator the problem is many orders of magnitude worse
kstrauser 4mo ago
It's dead simple to manage files in git or such. What Chezmoi adds over that are niceties like: * 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.
- theshrike79 4mo ago
  Also encryption with `age`. 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.
  - kstrauser 4mo ago
    Oh, that's slick. I haven't needed to do that yet and I keep my stuff in a private repo, but see the benefits to it.
    - 4mo ago

reinitctxoffset 4mo ago

[flagged]

tfrancisl 4mo ago
What a snakepit of a comment! I know there are tensions within nix but this feels like a classic case of Chestertons fence at a big scale.
- reinitctxoffset 4mo ago
  [dead]
- charcircuit 4mo ago
  These things really do not have an actual reason. Take for example the Nic people who go to every project with a bash script that uses #!/bin/bash and tells them to use #!/usr/bin/env bash. There is no justification for trying to fix every bash script in existence over the operating system being able to resolve what the "current" bash version should be (/usr/bin/env already has to pick a version). This is pointless O(n) busy work Nix people have created for themselves when an O(1) solution exists.
  - zaik 4mo ago
    If you decide to create a package for the project in nixpkgs, patch-shebangs.sh should do it for you, no?
    - reinitctxoffset 4mo ago
      Getting a patch into `nixpkgs` is not a reasonable bar for running some program you want to try. This is an (admittedly polite) way of saying more or less "you're holding it wrong". I respectfully disagree. For expert users, creating a flake and/or standalone derivation is a little more reasonable of an ask. It is an unreasonable ask of people who are considering adopting Nix, and the friction is artificial, it serves no practical benefit (you'll notice that things like `nix-ld` are in `nix-community` now, long-time community contributors like Mic92 said a long time ago, we need to stop the bleeding on this). And once you get out of the merely alienating to anyone used to being treated well, and into actually complex software builds, "possible once you learn the incantations" goes to "never happens, you will never run this without Docker on NixOS". I won't settle for that, so I fix things: ``` b7r6 on ultraviolence ~ nix run github:sensenet-ai/nvidia-sdk#python Python 3.12.12 (main, Oct 9 2025, 11:07:00) [GCC 15.2.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import tensorrt_llm W0619 15:07:35.110000 14798 /nix/store/xgk8wcis2avy1vsv66viw150jv78v6qs-ngc-python-packages-ngc-25.12-rootfs/lib/python3.12/site-packages/torch/utils/cpp_extension.py:2422] TORCH_CUDA_ARCH_LIST is not set, all archs for visible cards are included for compilation. W0619 15:07:35.110000 14798 /nix/store/xgk8wcis2avy1vsv66viw150jv78v6qs-ngc-python-packages-ngc-25.12-rootfs/lib/python3.12/site-packages/torch/utils/cpp_extension.py:2422] If this is not desired, please set os.environ['TORCH_CUDA_ARCH_LIST'] to specific architectures. [TensorRT-LLM] TensorRT LLM version: 1.1.0 >>> import torch >>> torch.cuda.is_available() True >>> ```

tfrancisl 4mo ago

If you like home manager but also like to understand how your "home"/user programs are configured, take a look at hjem!

drdexebtjl 4mo ago
Last time I looked, it only worked with NixOS. 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; Which is pretty much exactly the same syntax you get with Hjem, but with more optional features. So you could just write that instead whenever you want full control :)
- tfrancisl 4mo ago
  It works on darwin and any linux just fine. Theyre even working on a "standalone" like HMs, if you really want to decouple your user programs from your system. 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.
  - drdexebtjl 4mo ago
    I'll take a look again once it's a bit more mature. I need a standalone, single-user, rootless mode for it to work on all my systems. Thanks for the recommendation.