Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Using GNU Stow to manage your dotfiles (2012)

brandon.invergo.net

Post reply on HN
Print view View original

81–90 of 116 posts

Re: Using GNU Stow to manage your dotfiles (2012)

#81

Post by susam »

I follow a similar but handcrafted approach. I have a dotfiles repo with a setup script that automates the creation or deletion of all the symbolic links: https://github.com/susam/dotfiles/blob/master/setup

So what I do on any new system is just:

  git clone https://github.com/susam/dotfiles.git
  cd dotfiles
  ./setup
And if I want to undo all the setup for some reason:

  ./setup rm

Re: Using GNU Stow to manage your dotfiles (2012)

#82

Post by larusso »

wwright wrote: post #74
codethief wrote: post #34

Earlier quoted context omitted.

> My method is to write small scripts, I call them setuplets, Finally I have a proper term for what I, too, have been doing all these years! :-) It's indeed the best-possible approach I've found, though there are a number of things that I haven't yet solved for myself in a satisfactory manner: - With shell scripts there are no idempotency guarantees and there is no easy undoing / uninstalling / clean-up, especially a…

Have you played with NixOS or Guix at all? They attempt to solve this problem from the ground up for the entire OS. It obviously has trade offs, but IMO it is the best solution around today (other than Kubernetes, but that is an abstraction level higher).

I really love nix and nixOS and I‘m also using homemanager on my macOS machine and an WSL instance. But I decided to turn away from it. Using just the nix packagemanager on a distribution feels off and doesn’t bring you all the benefits. On macOS it can be very frustrating to find a programm that is in the mix packages but not available for macOS. Plus some tools tend to be very outdated and use very general compile settings (light theme etc). I also have issues how libraries etc are linked. I have a rust project that for the love of god I could not compile on a arch installation with nix package manager managing all tools (rustup, git, etc). It was failing with some error around a standard c lib. It was working fine on a popOS installation with nix so I have no clue what went wrong where. The rabbit hole is very deep with nix. It is very very awesome but you also leave behind the conventional way of Linux when going all in. I played around with nixOS and really loved the idea and how easy it is to reconfigure the system from a single config. But if you don‘t want to write custom package overrides and dable with nix-expressions I would not use it as a dotfilemanager. If anyone knows a good way to integrate nix with arch that does not feel like a strapped on solution I‘m all open.

Re: Using GNU Stow to manage your dotfiles (2012)

#83

Post by e40 »

devy wrote: post #72
nickjj wrote: post #29

Call me old fashioned but what's wrong with having a regular git repo anywhere you want with all of your dotfiles and them symlink those files to where they need to go? If you wanted to you could && a few symlinks and other commands into 1 copy / paste'able command to get up and running really quickly. It's also painless to manage secrets by sourcing in optional files. It also works nicely when you want files living…

> but what's wrong with having a regular git repo anywhere you want with all of your dotfiles and them symlink those files to where they need to go? Nothing wrong with tracking dotfiles with Git. It's probably the simplest and easiest approach without requiring any fancy tools other than Git. However, as mentioned in ArchLinux's wiki page, the disadvantage of Git approach is that "host-specific configuration generall…

I've had my dotfiles in git for 7+ years. Work on Windows, Linux and macOS. Conditionalization in BASH is dead simple.

EDIT: 12+ years at work.

Re: Using GNU Stow to manage your dotfiles (2012)

#84

Post by CUViper »

JoshTriplett wrote: post #67
nickjj wrote: post #29

Call me old fashioned but what's wrong with having a regular git repo anywhere you want with all of your dotfiles and them symlink those files to where they need to go? If you wanted to you could && a few symlinks and other commands into 1 copy / paste'able command to get up and running really quickly. It's also painless to manage secrets by sourcing in optional files. It also works nicely when you want files living…

> Call me old fashioned but what's wrong with having a regular git repo anywhere you want with all of your dotfiles and them symlink those files to where they need to go? I prefer to skip the symlinks, and just directly use the git repository as my home directory. (I have a sizable .gitignore for things I don't want to track.)

I do it with a renamed `.git` and a bash alias `githome` that points `git` to the right place. This way it doesn't look like my home is a repo in normal use.

Re: Using GNU Stow to manage your dotfiles (2012)

#85

Post by mssundaram »

nickjj wrote: post #29

Call me old fashioned but what's wrong with having a regular git repo anywhere you want with all of your dotfiles and them symlink those files to where they need to go? If you wanted to you could && a few symlinks and other commands into 1 copy / paste'able command to get up and running really quickly. It's also painless to manage secrets by sourcing in optional files. It also works nicely when you want files living…

> If you wanted to you could && a few symlinks and other commands into 1 copy / paste'able command to get up and running really quickly

Exactly! I do exactly that. I have an install.sh script that simply iterates over the files and directories in my dotfiles repo and does mkdir and ln

Re: Using GNU Stow to manage your dotfiles (2012)

#86

Post by kohlerm »

jpetrucc wrote: post #58
Kototama wrote: post #32

Earlier quoted context omitted.

Interesting! https://github.com/nix-community/home-manager uses Nix to solve this problem. It adds reproducibility and rollbacks but with the cost of learning the Nix DSL.

+1 for nix and home-manager - I recently switched to this setup (still learning/experimenting a lot, link here [0]) and have been very happy! [0]: https://github.com/jpetrucciani/nix

+1 for nix and home-manager. Most other solutions make it hard to manage installing packages on different flavors of Linux. You can get even more fancy by using the direnv integration to have specific versions of binaries available when entering a directory. See https://www.mathiaspolligkeit.de/dev/exploring-nix-on-macos/ . By checking in the nix files into your projects directory, you get really reproducible projects, because all you have to do is to checkout the project then run direnv allow and nix/home-manager will install all tools needed to run/build that specific projects. Different projects can use different versions of tools.

Re: Using GNU Stow to manage your dotfiles (2012)

#87

Post by kevin_thibedeau »

coldtea wrote: post #41
nickjj wrote: post #29

Call me old fashioned but what's wrong with having a regular git repo anywhere you want with all of your dotfiles and them symlink those files to where they need to go? If you wanted to you could && a few symlinks and other commands into 1 copy / paste'able command to get up and running really quickly. It's also painless to manage secrets by sourcing in optional files. It also works nicely when you want files living…

> Call me old fashioned but what's wrong with having a regular git repo anywhere you want with all of your dotfiles and them symlink those files to where they need to go? Well, that's what you end up with. Stow just automates the "symlink those files part".

More importantly, Stow can intelligently convert a symlinked directory into a real one when a second package wants to share it.

Re: Using GNU Stow to manage your dotfiles (2012)

#88

Post by kelnos »

ironmagma wrote: post #44
coldtea wrote: post #43

Earlier quoted context omitted.

> Right, but when you unlink it from your home directory, the file still exists in the git repo. That's a feature.

Not when you are looking for a workflow to make dealing with dotfiles faster and more painless. With the current (symlink based) setup, there is a hidden state you must hold in your head or else carefully inspect: the discrepancy between your git repo and your home directory. Maybe you forgot to link a dotfile, and that’s why your latest configuration doesn’t work. Ditto for unlinking a dotfile.

I delete dotfiles so infrequently (once a year?) that this just isn't a problem for me.

I also don't have all dotfiles under version control, just the ones I've essentially "built myself", so maybe that makes it easier.

Re: Using GNU Stow to manage your dotfiles (2012)

#89

Post by heroprotagonist »

curryst wrote: post #48
wbl wrote: post #6

Earlier quoted context omitted.

You mean what we had with project Athena for decades? Or NFS mounted homework? Or plan 9?

> Or NFS mounted homework? I would not wish this pain on others. It works great when your systems are homogenous. It rapidly becomes a pain when you need to make customizations that only apply in a particular network, or on hosts with a particular OS version, etc. My bashrc has basically just become a monstrosity to control what files get sourced for this particular host. Answering why a particular env car is set to…

I moved to splitting my bashrc into multiple files and having my main bashrc source them from a ~/.bashrcd directory.

At heart it's a short snippet that just checks for existence and sources each file in the directory:

https://github.com/targaryen/bashrcd/blob/master/install/ins...

I added aliases to list/edit/remove entries from the .bashrcd directory and resource it. And a script I can call with a one-liner to edit bashrc on a new machine to add the sourcing and the helper aliases.

It'll load alphabetically so I can prefix entries with a number to specify load order (defaulting to 0100 so I don't need to specify this in the commands unless I explicitly changed them).

So the end result is that I can quickly edit or create a new bashrc entry by running 'ebrc entryname'. This opens ~/.bashrcd/0100--entryname in vi, and when it's saved it'll re-source so the add/change takes effect immediately.

Or 'lbrc' to list contents of the directory, or 'rbrc entryname' to remove ~/.bashrcd/0100--entryname

It's fairly simplistic but takes away most of the cognitive load of managing a complex bashrc.

Re: Using GNU Stow to manage your dotfiles (2012)

#90

Post by josepmdc »

meagher wrote: post #56

You don't need symlinks, setup scripts, etc. Try this: 1. Bare git repo in your home directory ($HOME/.files) 2. Alias for prefixing git commands ("env GIT_WORK_TREE=$HOME GIT_DIR=$HOME/.files") 3. Strict .gitignore file (that ignores all files by default) Simple to add files: `h git add .vimrc` Have this set up for myself. Works great https://github.com/tmm/dotfiles

This is the simplest way of doing it and in my opinion the best. You can just have all of the files where they are supposed to be without the need of symlinks or anything. I've been doing it this way (well a bit different but very similar) and it works like a charm.

I explain here the steps of how I do it: https://github.com/josepmdc/dotfiles#2-if-you-want-to-manage...

Post reply on HN