[HN Gopher] Dotfiles Management
___________________________________________________________________
Dotfiles Management
Author : threeme3
Score : 141 points
Date : 2023-01-08 05:38 UTC (17 hours ago)
(HTM) web link (mitxela.com)
(TXT) w3m dump (mitxela.com)
| tomphoolery wrote:
| 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.
| j1elo wrote:
| In case it's useful for someone (xkcd.com/1053) I use stow for
| handling config files. Lastly featured in HN here:
| https://news.ycombinator.com/item?id=32253018
|
| 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.
| chadlavi wrote:
| 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.
| jonwest wrote:
| What happens when one of those computers blows up and you need
| to get back to being productive quickly?
| doubleunplussed wrote:
| Not the person you asked, but if that happens I restore from
| backup.
| jacobsenscott wrote:
| 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.
| asix66 wrote:
| Looks similar to what I'm doing to manage my dotfiles [0]
|
| I'll be refreshing this thread to see what others are using.
|
| [0] https://github.com/andersix/dotfiles
| _0xdd wrote:
| 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.
| fileeditview wrote:
| I also use this trick to manage my dotfiles. Here is another good
| tutorial about it:
| https://www.atlassian.com/git/tutorials/dotfiles
| wooptoo wrote:
| I use something similar but call it cfg:
| https://gist.github.com/radupotop/c1d2b77c24ddfcfae93d840f51...
|
| 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.
| neeh0 wrote:
| nix home-manager is really great at this (and declarative!)
| jonwest wrote:
| 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.
| davidhay wrote:
| Second dotbot.
| watusername wrote:
| 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.
|
| [0] https://github.com/nix-community/home-manager
| wkdneidbwf wrote:
| the read has "words of warning" almost immediately at the top
| about being familiar with nix first. it's the gateway drug to
| nix?
|
| bad docs and difficult to grok error messages seem to be a
| consistent theme that comes up learning nix.
| zamalek wrote:
| 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.
| zeorin wrote:
| 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.
| __MatrixMan__ wrote:
| It's definitely a gateway drug worth taking since Nix solves
| all kinds of other problems too.
|
| Just don't expect to become an expert overnight, it takes a
| while to sink in (or it did for me).
| unshavedyak wrote:
| 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)_
| woile wrote:
| I've just (literally a few hours ago) started a tool trying
| to follow those principles.
|
| 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:/
| unicornmama wrote:
| Nix is like sailing from Oakland to San Francisco on an
| aircraft carrier for your daily commute.
|
| 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.
| tjoff wrote:
| 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.
| djhworld wrote:
| I always start out with the best of intentions for dotfile
| mangement etc, using tools like stow, git and so on.
|
| 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
| dewey wrote:
| 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.
| snhly wrote:
| 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.
| Waterluvian wrote:
| Before your comment I never considered the inverse of
| .gitignore but apparently it's very easy to do!
| https://stackoverflow.com/questions/987142/make-gitignore-ig...
| SuperCuber wrote:
| 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 :)
|
| https://github.com/SuperCuber/dotter
| ckolkey wrote:
| 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
| RealCodingOtaku wrote:
| Nice!, I did a similar thing for my dotfiles[0], but with a
| script that backups existing configs[0]. There are other tools,
| but I like the git bare way better.
|
| [0] https://codeberg.org/codingotaku/dotfiles
| jsmeaton wrote:
| 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.
|
| [0] https://github.com/lra/mackup
| masto wrote:
| 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.
| ericvsmith wrote:
| 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.
| andersonvaz wrote:
| 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.
|
| [0] https://yadm.io
| g0xA52A2A wrote:
| 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.
| josephd79 wrote:
| This is what I do also.
| echelon wrote:
| That's clever, but it also seems like a bit of a hassle. It
| also seems incredibly non-hermetic and prone to accidental
| pollution.
|
| What about putting all configs into a single git managed
| directory and using tooling to install the appropriate
| symlinks?
| hermanradtke wrote:
| The git ignore file set up prevents accidental pollution.
|
| A script and/or symlinks is overhead.
| nerdponx wrote:
| # 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
| twp wrote:
| Bare git repos have lots of limitations, namely:
|
| * 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...
| ZeroGravitas wrote:
| "yadm" effectively does this, just replace "git" with "yadm"
| and it'll act on your $HOME
|
| 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/
| Karellen wrote:
| ~/.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`?!)
| jacobsenscott wrote:
| 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.
| leipert wrote:
| How do people here handle secrets like e.g. passwords / env
| variables / ssh keys in their 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.
| base698 wrote:
| Pass: https://wiki.archlinux.org/title/Pass
|
| Emacs uses .authinfo transparently:
| https://www.reddit.com/r/emacs/comments/7jhcq8/authinfogpg/
| spudlyo wrote:
| Emacs' auth-source.el can work directly with the macOS
| keychain, which if you're on a Mac is pretty useful.
| twp wrote:
| https://www.chezmoi.io/ supports:
|
| * 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....
| gillh wrote:
| 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.
|
| [0] https://github.com/fluxninja/dotfiles
| firstSpeaker wrote:
| Interesting, thanks for sharing. Two questions:
|
| Does this make a backup of an existing set of .files?
|
| Does this also install required packages using brew?
| gillh wrote:
| 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].
|
| [0] https://github.com/fluxninja/dotfiles/blob/master/sw/asse
| ts/...
|
| [1] https://github.com/fluxninja/dotfiles/blob/master/sw/bin/
| exe...
| bennyp101 wrote:
| Checkout chezmoi, I've been using it for a few years and it ticks
| every box for me - various machines, different configs, scripts,
| passwords etc
|
| https://www.chezmoi.io/
| pstuart wrote:
| On my list of new years resolutions is to finally embrace
| dotfiles management. This looks like just the ticket. Thanks!
| Barrin92 wrote:
| 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.
| txprog wrote:
| I discovered chezmoi a few days ago after getting a new laptop
| and a wish to normalize my configuration across multiple
| computers.
|
| Templating is awesome when having computers with differents DPI
| or screens attached, OS, etc.
|
| Edition with --watch is a breeze, auto commit too!
| theshrike79 wrote:
| And best of all: it's a single executable that doesn't need any
| specific installing.
| CamJN wrote:
| 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.
|
| [1] https://www.chezmoi.io/user-guide/frequently-asked-
| questions...
| saintfiends wrote:
| 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.
| twp wrote:
| You can use chezmoi to manage files outside your home
| directory if you really want to.
|
| 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`).
| EnigmaCurry wrote:
| I haven't needed to keep track of dotfiles per se, but for
| servers I need to track changes to /etc and for that I use
| Etckeeper[1]
|
| 1 https://wiki.archlinux.org/title/Etckeeper
| lucideer wrote:
| 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(tm)". 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.
___________________________________________________________________
(page generated 2023-01-08 23:00 UTC)