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
I haven't started using templates and things, for now it's just environment variables.
[1]: https://chezmoi.io
Mine uses Homebrew to install my favorite binaries and also runs a zsh script to configure macOS defaults how I like it.
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.
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.
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)
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.
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 use:
git init --bare $HOME/.myconf
alias config='/usr/bin/git --git-dir=$HOME/.myconf/ --work-tree=$HOME'
config config status.showUntrackedFiles no
where my ~/.myconf directory is a git bare repository. Then any file within the home folder can be versioned with normalcommands like:
config status
config add .vimrc
config commit -m "Add vimrc"
config add .config/redshift.conf
config commit -m "Add redshift config"
config push
And so one…No extra tooling, no symlinks, files are tracked on a version control system, you can use different branches for different computers, you can replicate you configuration easily on new installation.
[1] https://www.chezmoi.io/user-guide/frequently-asked-questions...
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.
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?
Templating is awesome when having computers with differents DPI or screens attached, OS, etc.
Edition with --watch is a breeze, auto commit too!
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...
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
~/.dotfiles
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`?!)
[0] 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...
Has a couple of other nice things specific to this use case, like letting you have slightly different files based on username or platform.
To make this manageable, I added this .gitignore:
\*
!.\*
!.hammerspoon/\*/\*
!.config/\*/\*
!.ssh/config
.DS_Store
.bash_history
.tig_history
.lesshst
.python_history
.wget-hsts
.zsh_history
.CFUserTextEncoding
.Xauthority
/.config/mcd/.cache/
/.config/mcd/.local/
/.config/legendary/
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.
What about putting all configs into a single git managed directory and using tooling to install the appropriate symlinks?
# 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 originA script and/or symlinks is overhead.
Really recommend investing in common dotfiles at the organization level. For young developers, a standard setup provides a big productivity boost.
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...
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....
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.
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.
~/usr/src/p/dotfiles git worktree list
/home/matt/usr/src/p/dotfiles 160721b5e3 [master]
/home/matt/.config e195a59c7b [config]
/home/matt/.gnupg b50725b47c [gnupg]
/home/matt/.mozilla b5d0d07b74 [mozilla]
/home/matt/.mutt f3d4a14d99 [mutt]
/home/matt/.tmux a93aa509af [tmux]
/home/matt/.vim 68fd61921c [vim]
/home/matt/.weechat ef3d4c761f [weechat]
/home/matt/.zsh 228ee42367 [zsh]
/home/matt/bin b05de7d9d7 [bin]
/home/matt/usr/venvs/shell 6a3b7e4c6a [shell/venv]
/home/matt/usr/venvs/npm d2065c68bf [shell/npm]
And only two symlinks I manually manage /home/matt/.vimrc -> .vim/.vimrc
/home/matt/.zshrc -> .zsh/zshrc
Everything else isn't versioned. I rely on btrfs snapshots and back ups.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.
https://github.com/sontek/homies
1. I use a `justfile` that calls `nix profile install ...` to install my packages, rather than using a nix configuration file. This allows me to use a standard package manager workflow rather than going "all in".
https://github.com/sontek/homies/blob/master/justfile#L24-L2...
2. I then use GNU Stow to install my dotfile configuration:
https://github.com/sontek/homies/blob/master/justfile#L93-L9...
I think this is a great middle ground where I can utilize `nix` as my package manager across Linux and Mac and have consistency while not having to learn the whole configuration language or change my workflow.
The other tools I use heavily in my environment:
- https://asdf-vm.com/: I find this better than installing python/node/etc from nix.
- https://github.com/casey/just: I use this as my command runner (similar to make but cleaner in my opinion)
although, nice idea on tracking the whole / instead of just ~/!
the only thing I miss after aliasing dotfiles to git, is that you lose git's autocompletion features. I once tried to set it up in zsh with autocomp, but without success, should review that
I guess what I should be doing is adding if statements into all of my config files, but instead I wind up just copy/pasting the parts of config that I like from my github repo and never actually doing real dotfile management. Which just leads to the repo becoming stale.
- "The best way to store your dotfiles: A bare Git repository" : https://news.ycombinator.com/item?id=19591033
- Also see: "The best way to store your dotfiles: A bare Git repository EXPLAINED" : https://www.ackama.com/what-we-think/the-best-way-to-store-y...
I hardly ever need to sync things between machines since vscode manages that itself.
I get why some people need this but it's a net time sync for a lot of people that probably don't need it.
Willing to bet it's mostly due to a lack of backups and ability to restore them to a new machine when you upgrade.
One nice thing about this is that you can keep a central repo for multiple machines and use branches with rebase and merge to sync changes while keeping specific differences separate.
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?
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.
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.
I’ll be refreshing this thread to see what others are using.
I am not complaining about the repeat. It’s just that I find it very amusing to see different people kinda-sorta reinventing the wheel (and discussing the nuts and bolts) again.