I was interested in chezmoi, but they don't want you[1] managing files outside your home directory which made it a non-starter. I need to manage /etc/ and /usr/local/ too.
I've been using chezmoi too and this is the only feature I miss. It'd be interesting to know what solutions folks are using. Chezmoi has some discussions around it, mostly recommending to use run scripts.
I've partially adopted `aconfmgr` for the other stuff, but haven't put in the effort to refine my config, partly because I only have one applicable (arch-based) system at the moment.
I didn't discover Chezmoi until seeing this thread (sigh). I developed a tool, filetailor, with an almost identical goal (dotfile management while accounting for differences across machines). It uses Python and YAML, but from what I can tell is similar in concept to Chezmoi.
One thing I like about filetailor I didn't see in Chezmoi was the ability to surround code with a comment specifying which machines it should be commented/uncommented for. It's easier than templates in some situations.
It works great, but there's probably tons of bugs that occur when used by someone other than me. I don't have a CS background and this was my first big hobby project.
I'm curious about, specifically, which files you (and the sibling commenter) want to manage outside of the home directory. Is it OS package-manager configs?
This is highly dependent on distro, but for any use-cases where editing /etc/ is the recommendation, I have found that either:
(a) It's a development environment thing (e.g. httpd vhosts) & thus I see it as quite separate to "my dotfiles" (a personal machine env thing): I try my best to manage dev env stuff from project-specific repos wherever I can (i.e. a bash script to dispatch required local /etc/ changes in a repo "./scripts" dir or similar), or otherwise if it's a more significant set of configs, Ansible.
(b) It's a specific app that is recommending doing things the "Wrong Way™". There's often a workaround to get it to use $HOME or $XDG.
(c) It's OS package configs. I've found that things like repo & key installs are well suited to chezmoi run_ scripts. For anything more advanced or esoteric, I guess that may be an exception.
regular config files in ~/Library/Application Support/
Sure there are (b) workarounds, including chezmoi templates and run_ scripts with symlinks, but that's cumbersome (and some issues were only resolved recently)
settled on this as well because of its very good cross-platform support. Only thing that took some time getting used to was the model of having a source directory distinct from your actual dotfiles unlike most of the symlink based tools.
I'm in the process of migrating over to this. I find it much simpler and easier to configure than dotbot (which I had be using for many years). If you're only using your dotfiles on one platform, really anything will work. Where things get hairy is when you want slight tweaks or configuration changes depending on platform. Chezmoi gets this right out of the box.
been using chezmoi for the past 3 months across 4 machines. i like the template support, but i constantly feel like there's complexity hiding. im finding myself needing to relearn various bits of how it works after not touching it for a few weeks at a time.
by far, my favorite thing about chezmoi is that you're managing a separate set of files and syncing then to your homedir, making it reallllllly easy to switch tools or otherwise do something else.
its better than the home-rolled symlink solution i was using before it, and certainly better than some of these turn-your-home-dir-into-a-git-repo solutions.
but if im being honest, i hate every one of these tools in different ways. i dont have the answer, but i feel like im endlessly searching for something that feels like the right balance of simple and flexible.
My homebrew solution uses comments surrounding or in-line with the code that is machine-specific. The program then uncomments/comments the code appropriately as it is backed up and restored.
What do you think of this approach? Would that remove the complexity hiding?
The program works great for my use case, but I don't have a CS background and this was my first big project, so I'm sure it's full of bugs and poor coding practices.
Nice hack, but I still believe that home-manager [0] should be the way to go. It's the gateway drug to the Nix ecosystem and cleanly solves the composability problem which this "one-size-fits-all repo checked out to root" approach will have some trouble with.
It's sad though - there's almost nothing in Nix (in my experience) that has to be that difficult if you know any programming. It's a perfect storm of bad documentation, bad tooling and unintuitive UX.
I've been half tempted to try and bridge Nix with some simplified UX. Something resembling blasphemy but nonetheless focused on user experience above all else. At least doing that would be a natural project to learn Nix better, too heh.
(disclaimer: I use Nix[OS] on two machines and my macbook. I know it decently.. but far from where i'd expect given it's my primary OS and package manager)
For me the killer feature of home-manager versus other dotfiles managers is that it also installs any software your dotfiles depend on or assume to be present on the machine.
To me it is marking what is “garbage” vs what isn’t in the .config folder. I like to experiment on linux a lot, like switching to plasma and back to Gnome and it always leaves like 20 mostly-empty folders trashed. I can then just remove the folder and go on my way with home-manager.
If you're running NixOS there's an impermanence plugin that allows you to specify specific directories and files you need to persist outside of what NixOs/HM builds for you and then use a tmpfs in-memory partition for root and/or home. Then at boot you're loading up the NixOS/HM config and then the persistent files are symlinked or mounted to where they need to be, but otherwise you have a fresh system on each reboot. It's a bit painful and manual to figure out exactly what to keep (unless you just want to keep the entire .config, for instance, which I don't) but it's amazing to know that you can mess up your home directory as much as you want and then it'll automatically clean itself with a reboot.
You're only likely to screw things up once you start digging deeper into the Nix language/stdlib. I was put off by the warning at first as well, but it's honestly awesome having functional dotfiles that work reasonably consistently across NixOS (personal)/Ubuntu (work)/MacOS (work).
> bad docs
Yeah, pretty damned awful.
> error messages
That too.
I honestly think that inventing a language was a huge mistake. Guix took a much more sensible approach, but a libre kernel is unusable for 99.9999% of people.
Honestly, it really is not the language that’s the problem. While there are a few cases where it can trip you up at first, you wouldn’t be singing package descriptors even if it were Python — it simply has a business domain which is non-trivial. This non-triviality and organic growth show on the standard library of nix packages, but I fail to see how a lisp language or whatever be immune to it, besides having learned from some early abstractions mistakes.
And one might even argue the opposite, a DSL made for creating packages may well be better. Especially that plenty of package descriptions are basically reads like JSON.
Nix is a huge dependency though, in a lot of sense (have to learn a new programming language rather than invest in your git skills etc.). Even if you are mostly running nixos.
But ideally no year will go by without using it, because you do install it to another system, tweak your home config, etc. The same way one doesn’t forget most of git, even though that one has some arcane UX.
95% of the time if I'm making nix a dependency it's just to install the correct version of python and poetry, then I let poetry handle the other dependencies. So it's totally possible to just use nix a little. My coworkers haven't even noticed the flake.nix in our repo, they just install those things by hand.
But then there's that 5% case where you do have to forge a demonic pact with the nix gods, and it's handy to have your summoning circle all warmed up and ready to go.
Pandas is one of those for which poetry alone doesn't do the job. So I have nix install pandas alongside poetry so that when poetry tries to install pandas, the non-python dependencies are all lined up.
It works well on all of my linux boxes. On my mac it takes forever because it wants to rebuild the linux universe. Given that the system architecture is a parameter, I think there should be a way to rewrite my flake (or update the nixpkgs numpy) to just rely on bsd tools in those cases, but I haven't found it yet.
That's what's holding me up from recommending it to my team. I'm happy to just use linux everywhere, but they aren't.
Actual "military grade tech" assumes field service by minimally trained personnel and an efficient logistic chain of supply. This is is the opposite of Nix, which requires months of self-training futzing around with obscure commands and an obscurer language, backed by an out of date unsorted mound of documentation and recipes.
My current dotfile management makes heavy, near complete, usage of home-manager. If I want to do a redeployment I can simply install home-manager on a fresh installation, checkout my repository, and perform `nixos-rebuild switch`.
Any home-manager users on NixOS here? Are there any killer features in home-manager for you? I tried home-manager for a bit, but just went back to plain NixOS after I couldn't find anything it did better than what I was already using ([1], [2]).
Easy integration between the two. I pass config from the system config to home config for some things and it’s quite seamless. Also one command to apply config for system and home is nice.
I use NixOS and do not use home-manager. I have synchthing managed by NixOS and it syncs all of my config and files between all my machines.
Btw, am I the only person annoyed at calling configuration files dotfiles? Not all hidden files/folders are configuration, and not all configuration files are hidden.
I was unhappy with existing solutions, especially I wanted the ability to handle differences between machines. So I built my own! You're welcome to see if you like it :)
I've been using dotter for over a year and it's incredible. I use the same dotfiles repo for Mac and Linux, and dotter is super easy to change variables or subscribe a machine to specific configs. Thanks a lot for dotter @Supercuber!
I'm a fan of just having my $HOME as a plain git repo with "*" in ~/.gitignore. Having to force add new files is a minor chore but one I'm more than happy to live with.
# Save the repo to `~/.dotfiles`; the `--bare` option prevents Git from making
# a mess of your home directory.
git clone --bare ... ~/.dotfiles
# Set up an alias for this shell session (it's also in ~/.config/aliasrc).
alias dots='git --git-dir=$HOME/.dotfiles --work-tree=$HOME'
# Make sure we don't show untracked files in `git status` output.
dots config --local status.showUntrackedFiles no
# Checkout all local files.
# NOTE: This might overwrite existing files, or you might need to stash files
# before proceeding. Look before you leap. If you have an existing setup,
# consider checking out individual files as needed and testing the
# configuration piecemeal, instead of doing a complete checkout.
dots checkout
# Make sure we can access remotes properly. The `--bare` option requires us to
# do this manually.
dots config remote.origin.fetch "+refs/heads/*:refs/remotes/origin/*"
# Make sure we are set up to track the remote `master` branch. Again, this is a
# consequence of cloning with `--bare`.
dots branch --set-upstream-to=origin/master master
dots switch master
# Fetch to make sure everything is configured correctly.
dots fetch origin
This makes use of the fact that .gitignore patterns are evaluated in order. It basically makes git only care about dotfiles in the home directory, files under .config, .ssh and .hammerspoon. Specific files/dirs that match that filter can still be ignored (e.g. .bash_history).
This is very straightforward and works quite well, so I don't see the need for yadm anymore. The one issue I have with it, is that in the terminal I'm always in a git context (shown in the shell prompt) in any directory under $HOME.
I also track my dotfiles in a Git repo, but I only track my home directory. Made a tool to help out with some of the more arcane commands: https://github.com/tubbo/homer. I'm currently rewriting it in Rust, which is mostly done but I still have to work out a couple kinks on Linux machines . So far, I haven't needed to mess with too many top-level configs on each machine, most of the stuff I do is relatively contained (and uses the XDG standards thankfully). It got a little hairy when I tried to configure certain file paths on both a Linux and macOS environment, as there are different default conventions and other nuances that make the two not fully compatible at times. But it definitely saves a lot of time when setting up a new machine from scratch, `homer bootstrap $REPO_URL` does all the hard work and gets my home directory loaded up with configuration the way I'd expect.
It does however need a bit of preparation for complex things like Electron-based apps. I don't want to stow non-essential files and dirs, so I ended complementing it with a small script to do some preparation before the stowing itself.
I used to put a lot of effort into trying to sync dot files. And you know what? I don't see a reason to do it. I only have one work computer and one personal computer.
I don't need to sync between computers to accomplish that. Could just use something as simple as Dropbox.
BUT ALSO: There's nothing that important in my personal dot files. And anything work related is in specific git repos. I could be productive with the default zsh on a fresh install of macOS by installing home brew and a few packages.
I also haven't had a mac "blow up" in... 20 years?
I used to run several VMs for several projects, and it was convenient. But now I really just have a single work project, and don't really code on my personal computer. So I no longer need it.
Dotbot (https://github.com/anishathalye/dotbot) has worked extremely well for me. It’s simple to setup, has minimal dependencies, and it is also easy to run arbitrary commands if I want to get tricky with things. I would highly recommend it.
I very recently put some effort into tidying up my dotfiles, and have a brief writeup at https://chatwithsysop.com/blog/2022/12/31/dotfiles-cleanup (none of this was done with the academic rigor required to withstand a deconstruction by HN, it is just a log of one person's experience with a weekend project).
I chose to use yadm (http://yadm.io) for no particular reasons beyond that I found it first, and it seemed reasonable. It's more just a wrapper around putting GIT_DIR elsewhere.
I can't say enough good things about yadm. I found a yadm bug under Cygwin years ago, and the author had a patch for me within a day. I'll grant that Cygwin is an odd platform.
I use yadm to manage dotfiles across Windows (via Cygwin), macOS, and Linux.
Really? Just as so many utilities are finally moving away from `~/.foo` to `$XDG_CONFIG_DIR/foo` (default `~/.config/foo`) to reduce home directory pollution, does a new tool have to start using `~/.foo`?
Heck, even the `dot` output demo'd by TFA shows 8 legacy `~/.foo` files, but 10 `~/.config/foo(/bar)*` files. (But is missing `~/.dotfiles`?!)
This isn't a new tool. It is just a single convenient shell alias for any file on the system with git. You can put the repo in $XDG_CONFIG_DIR/dotfiles or wherever you want. ~/.dotfiles is just a common place to put that repo.
I use git-crypt with VCSH for dotfiles and Ansible for provisioning, using Ansible's built-in encryption for some data. It works pretty well, but to make things less annoying, I prompt for decrypt passwords up front and if typo it, you won't know until much later when bringing a machine up from scratch.
I'm a BSD user, so I tend to gravitate towards using rcs. Took a little while to get the muscle memory down, but it does work well for keeping track of my dotfiles.
Exactly the same for me, at some point I realized that just copying over some config files from a backup is easier than trying to keep things neat and tidy for years just to be prepared for setting up a new computer every few years.
At our startup (FluxNinja), we provide MacBooks and Linux Desktops (System76) to our engineering staff. We have invested in common dotfiles[0] to help them keep dev experience consistent across machines. We use chezmoi for dotfiles management.
Really recommend investing in common dotfiles at the organization level. For young developers, a standard setup provides a big productivity boost.
1. It doesn't do a good job in making a backup of existing files as it's meant to be setup on a new machine. However, the setup script can be quickly modified to backup existing files. See [0].
2. Yes, it installs required packages via brew both on macOS and Linux. See [1].
This isnt a vcs based solution, but I've been using syncthing to track my configs, with the help of a small home server. The bonus is that it automatically synchronises my work and personal laptops without me needing to do anything
I moved away from using a dotfiles repo a few years ago because I kept forgetting to add/commit files as I changed them.
Instead I use mackup[0] which automatically manages symlinks to your Dropbox/Drive/Share and has support for a huge amount of software by default. You can also manually add “extra” files you wish to track if you like.
I have a similar system: I manage my dot files and a bunch of other configs by placing a git repository in my operating system's root directory, i.e. file:///.git. I use a .gitignore file to exclude most things from consideration while adding things to git. Transferring to another OS is as simple as copying the .git dir over.
This is cool, but I actually place ignored paths into the gitignore manually. This way I will always see reminders when a new file needs to be tracked or ignored. Otherwise I would forget to track new config files. E.g. when a new program is installed, its binary will be ignored by a previous rule added to gitignore (/use/bin/*), but its newly created config files in /etc will come up red when I run `git status`.
YADM[0] is another great tool for this very purpose which I've been using for years in combination with homebrew to setup any new (Mac) machine that I get and have everything from dotfiles to Applications installed in no time.
I do something similar, albeit a bit more bare-bones. I keep my dotfiles in a dotfiles folder that is a git repo and then just have a simple script to symlink everything.
I have a couple of submodules in there (zplug, pyenv) and a bash script to keep them up to date, and then a few self managed binaries, like fnm. That's about it.
I don't bother trying to manage anything outside of home or deal with secret values by using something like git-secret.
Overall, it works great and has allowed me to keep track of how my core tools are configured without too much hassle.
142 comments
[ 3.3 ms ] story [ 178 ms ] threadhttps://www.chezmoi.io/
Templating is awesome when having computers with differents DPI or screens attached, OS, etc.
Edition with --watch is a breeze, auto commit too!
[1] https://www.chezmoi.io/user-guide/frequently-asked-questions...
1 https://wiki.archlinux.org/title/Etckeeper
For an example, see https://github.com/felipecrs/dotfiles:
The `home` directory contains home directory files.
The `root` directory contains root directory files (e.g `/etc`).
https://github.com/k4j8/filetailor
One thing I like about filetailor I didn't see in Chezmoi was the ability to surround code with a comment specifying which machines it should be commented/uncommented for. It's easier than templates in some situations.
It works great, but there's probably tons of bugs that occur when used by someone other than me. I don't have a CS background and this was my first big hobby project.
This is highly dependent on distro, but for any use-cases where editing /etc/ is the recommendation, I have found that either:
(a) It's a development environment thing (e.g. httpd vhosts) & thus I see it as quite separate to "my dotfiles" (a personal machine env thing): I try my best to manage dev env stuff from project-specific repos wherever I can (i.e. a bash script to dispatch required local /etc/ changes in a repo "./scripts" dir or similar), or otherwise if it's a more significant set of configs, Ansible.
(b) It's a specific app that is recommending doing things the "Wrong Way™". There's often a workaround to get it to use $HOME or $XDG.
(c) It's OS package configs. I've found that things like repo & key installs are well suited to chezmoi run_ scripts. For anything more advanced or esoteric, I guess that may be an exception.
Why chezmoi doesn't use symlinks: https://www.chezmoi.io/user-guide/frequently-asked-questions...
General design FAQs: https://www.chezmoi.io/user-guide/frequently-asked-questions...
by far, my favorite thing about chezmoi is that you're managing a separate set of files and syncing then to your homedir, making it reallllllly easy to switch tools or otherwise do something else.
its better than the home-rolled symlink solution i was using before it, and certainly better than some of these turn-your-home-dir-into-a-git-repo solutions.
but if im being honest, i hate every one of these tools in different ways. i dont have the answer, but i feel like im endlessly searching for something that feels like the right balance of simple and flexible.
anybody wanna join my dotfiles-aas startup?
What do you think of this approach? Would that remove the complexity hiding?
https://github.com/k4j8/filetailor#example-usage
The program works great for my use case, but I don't have a CS background and this was my first big project, so I'm sure it's full of bugs and poor coding practices.
[0] https://github.com/nix-community/home-manager
Just don't expect to become an expert overnight, it takes a while to sink in (or it did for me).
I've been half tempted to try and bridge Nix with some simplified UX. Something resembling blasphemy but nonetheless focused on user experience above all else. At least doing that would be a natural project to learn Nix better, too heh.
(disclaimer: I use Nix[OS] on two machines and my macbook. I know it decently.. but far from where i'd expect given it's my primary OS and package manager)
https://github.com/woile/npt
I still don't know if it's worth, I have to experiment a bit more with it.
I have to say I'm still struggling with the flake:/
A really good LSP could do wonders for user experience.
bad docs and difficult to grok error messages seem to be a consistent theme that comes up learning nix.
> bad docs
Yeah, pretty damned awful.
> error messages
That too.
I honestly think that inventing a language was a huge mistake. Guix took a much more sensible approach, but a libre kernel is unusable for 99.9999% of people.
1. invest a lot of time in learning nix (nixos in my case)
2. set up a system that works great
3. a year or two go by
4. need to make a change, modification, or set up another system
5. relearn everything from step 1
That said, I really do like the system. Just wish it were more user friendly and better documented.
But ideally no year will go by without using it, because you do install it to another system, tweak your home config, etc. The same way one doesn’t forget most of git, even though that one has some arcane UX.
I'm running nix-build daily...
I love nixos but home-manager is just too much to force into all my other machines.
Most stuff I care about factors out into .config which I turn into a git repo, push to GitHub and slap on a CI checks for secrets.
Most engineers don’t need to forge a demonic pact with the Nix gods who demand I upend and replace everything from my operating system to my wife.
But then there's that 5% case where you do have to forge a demonic pact with the nix gods, and it's handy to have your summoning circle all warmed up and ready to go.
Here's a (too verbose, sorry) example: https://stackoverflow.com/a/74944857/1054322
It works well on all of my linux boxes. On my mac it takes forever because it wants to rebuild the linux universe. Given that the system architecture is a parameter, I think there should be a way to rewrite my flake (or update the nixpkgs numpy) to just rely on bsd tools in those cases, but I haven't found it yet.
That's what's holding me up from recommending it to my team. I'm happy to just use linux everywhere, but they aren't.
But, now that you're using Nix, ... you could use Nix to describe an OS setup, write Docker images, declare the tooling for a dev environment, etc.
[1] https://gitlab.com/engmark/tilde
[2] https://gitlab.com/engmark/root
Btw, am I the only person annoyed at calling configuration files dotfiles? Not all hidden files/folders are configuration, and not all configuration files are hidden.
https://github.com/SuperCuber/dotter
What about putting all configs into a single git managed directory and using tooling to install the appropriate symlinks?
A script and/or symlinks is overhead.
Has a couple of other nice things specific to this use case, like letting you have slightly different files based on username or platform.
https://yadm.io/
* Maintaining per-machine configurations is a hassle, usually involving a lot of manual branch juggling.
* There's no support for storing secrets in a password manager or in encrypted files.
Read more reasons why dotfile managers are better than bare git repos at https://www.chezmoi.io/why-use-chezmoi/#i-already-have-a-sys...
To make this manageable, I added this .gitignore:
This makes use of the fact that .gitignore patterns are evaluated in order. It basically makes git only care about dotfiles in the home directory, files under .config, .ssh and .hammerspoon. Specific files/dirs that match that filter can still be ignored (e.g. .bash_history).This is very straightforward and works quite well, so I don't see the need for yadm anymore. The one issue I have with it, is that in the terminal I'm always in a git context (shown in the shell prompt) in any directory under $HOME.
It does however need a bit of preparation for complex things like Electron-based apps. I don't want to stow non-essential files and dirs, so I ended complementing it with a small script to do some preparation before the stowing itself.
BUT ALSO: There's nothing that important in my personal dot files. And anything work related is in specific git repos. I could be productive with the default zsh on a fresh install of macOS by installing home brew and a few packages.
I also haven't had a mac "blow up" in... 20 years?
I chose to use yadm (http://yadm.io) for no particular reasons beyond that I found it first, and it seemed reasonable. It's more just a wrapper around putting GIT_DIR elsewhere.
I use yadm to manage dotfiles across Windows (via Cygwin), macOS, and Linux.
Heck, even the `dot` output demo'd by TFA shows 8 legacy `~/.foo` files, but 10 `~/.config/foo(/bar)*` files. (But is missing `~/.dotfiles`?!)
I've written simple encrypt/decrypt with PGP, but since I've kinda lost trust into Keybase I have no simple way to bootstrap PGP.
Emacs uses .authinfo transparently: https://www.reddit.com/r/emacs/comments/7jhcq8/authinfogpg/
* Keeping secrets in your password manager (all major password managers are supported), see https://www.chezmoi.io/user-guide/password-managers/.
* Encrypting entire files with gpg or age, see https://www.chezmoi.io/user-guide/encryption/.
You can also bootstrap your gpg/age private key on a new machine with a passphrase, see https://www.chezmoi.io/user-guide/frequently-asked-questions....
Eventually I get lazy and don't bother checking stuff in and forget where half of the stuff is.
Might try this solution but I'm too cynical to think it'll be something I'll stick with
Really recommend investing in common dotfiles at the organization level. For young developers, a standard setup provides a big productivity boost.
[0] https://github.com/fluxninja/dotfiles
Does this make a backup of an existing set of .files?
Does this also install required packages using brew?
2. Yes, it installs required packages via brew both on macOS and Linux. See [1].
[0] https://github.com/fluxninja/dotfiles/blob/master/sw/assets/...
[1] https://github.com/fluxninja/dotfiles/blob/master/sw/bin/exe...
Each local user has its own branch so this works: cfg push -u origin $USER
It's limited to the $HOME config files only, /etc has a separate git repo.
Instead I use mackup[0] which automatically manages symlinks to your Dropbox/Drive/Share and has support for a huge amount of software by default. You can also manually add “extra” files you wish to track if you like.
[0] https://github.com/lra/mackup
[0] https://yadm.io
I’ll be refreshing this thread to see what others are using.
[0] https://github.com/andersix/dotfiles
I have a couple of submodules in there (zplug, pyenv) and a bash script to keep them up to date, and then a few self managed binaries, like fnm. That's about it.
I don't bother trying to manage anything outside of home or deal with secret values by using something like git-secret.
Overall, it works great and has allowed me to keep track of how my core tools are configured without too much hassle.
Using GNU Stow to manage your dotfiles (2022) https://news.ycombinator.com/item?id=32253018
Mine uses Homebrew to install my favorite binaries and also runs a zsh script to configure macOS defaults how I like it.
I haven't started using templates and things, for now it's just environment variables.
[1]: https://chezmoi.io
Inside that directory I have a “dotfiles” subdirectory that has managed versions of my home directory dotfiles which I symlink in.
I've been using git and tarballs to synchronize my ~/.config across half a dozen hosts.