6 ms·

Home in Nix – dotfile management

122 points by devhugo 7y ago

DarkWiiPlayer 7y ago
I just clone my dotfile repo from github into ~/darkrc and include the config files I want on each system, so my ~/.bashrc will have a "source $HOME/darkrc/bashrc" at the end, ~/.config/ranger/rc.conf will have "source ~/darkrc/ranger.conf", etc.
- devhugo 7y ago
  That's certainly one option. The unique thing about dotfiles is that everyone has a different 'best solution'. The setup outlined in my post has the advantage of being highly configurable and programmable. However, for some people it might make more sense to use a plain git repo with symlinks as installing Nix on all their devices could be a nonstarter. I'm curious, what do you use to manage tools that don't have a `source $SOME_PATH` option. Do you symlink?
  - pletnes 7y ago
    I used to symlink and have a simple dotfiles repo, but this forces you to have exactly identical rc files. Different computers simply need different setups, so I started with ansible and a few playbooks running locally.
    - roryrjb 7y ago
      This was posted recently https://drewdevault.com/2019/12/30/dotfiles.html https://drewdevault.com/2019/12/30/dotfiles.html, but I actually liked the idea of using uname, hostname etc in constructing $PATH and even though I was already using git to track my dotfiles I adapted some parts of my setup like Drew describes and made $HOME a git repo itself ignoring everything by default. Works quite well across different OSs, machines and shells.
  - DarkWiiPlayer 7y ago
    Generally speaking, I avoid those tools. One example where this happens is rifle; in that case I just have a symlink. Alternatively, one could also just get a standalone C preprocessor and add a git hook to recompile files whenever you commit/pull some new changes.
tyrion 7y ago
Nice post, thanks for sharing. I currently use vcsh and myrepos and they work great for me. Now that I switched to Nixos maybe I could give home-manager a try. I wrote about my approach here in case you are interested ( https://germano.dev/dotfiles/ https://germano.dev/dotfiles/ )
- devhugo 7y ago
  Interesting. Home manager will enable you to manage your dotfiles. The more interesting proposition comes from Nix. I've absolutely loved using it in general and run NixOS by choice as my desktop OS. The great thing about using Nix and Home Manager to manage dotfiles is that your configuration is defined in a programming langauge. You have broad scope to control things based on whatever environment you are deploying the files to. It's a really powerful solution, it just takes a bit more time than some other dotfile systems. Give Home Manager a go if you have time to tinker, and if you have questions feel free to contact me through my email on my homepage.
trevorrr 7y ago
Would prefer GNU stow for simplicity. https://www.gnu.org/software/stow/ https://www.gnu.org/software/stow/
- codebeaker 7y ago
  GNU Stow is _great_ for this. I have the following in my dotfiles dir: [~/code/dotfiles]$ tree -a -R -L 2 ├── aws │ └── .aws ├── git │ ├── .gitconfig │ └── .gitignore_global ├── .gitignore ├── .gitmodules ├── gpg │ └── .gnupg ├── README ├── ssh │ └── .ssh ├── tmux │ ├── .tmux │ └── .tmux.conf ├── vim │ ├── .viminfo │ └── .vimrc └── zsh ├── .oh-my-zsh └── .zshrc I can then stow any of these into my home dir with: $cd ~/code/dotfiles $ stow -t $HOME git That sets up a link from all the files in my home dir like: .gitconfig -> code/dotfiles/git/.gitconfig
- devhugo 7y ago
  I've looked at and read about other's experiences with stow in the past. I'm uncertain about this so please correct me where I am wrong, but the issues I see with stow are: 1. It's somewhat dated/may have a tail of legacy features 2. I'm unsure of it's value beyond of what can be provided via the Git Bare Repo solution linked in the intro of my post. 3. More importantly, it's not a programmable solution where you can override default files based on the current system. The main value proposition I see in my system is that I can define a single default configuration for, say, my terminal Alacritty, and override the configuration where necessary based on either my user, machine or role. Nix is a programming language, so I essentially have my system configuration managed via a programming language and can control things with a great level of detail.
  - padthai 7y ago
    I use Stow, it is simple and only does a few things, but for a lot of users like me it is more than enough: 1. Probably it will not receive more features any time soon. 2. You can have several configurations and mix them, also it makes very easy to adopt changes from the current system and/or rollback changes. 3. No, it is not programmable, but you can have several folder for different systems and configurations. I for example have a folder called unix for all *nix systems, other called x11 for x11 programs, darwin for macOS, etc. You could do the same with roles. If you want really fine grained control over machine/user/role, it is not enough, and it does not take into account package managing at all. I use a mix of Stow/Ansible for Desktops and HashiCorp/Ansible for the `cattle`. Nix is more powerful than my setting, but I still need to evaluate if it is flexible enough for the orgs I work with.
the_duke 7y ago
I tried out Nix recently, with the intention of using it to get declarative management of my user account. I discovered too late that Nix basically has no support for this. While NixOS has some very nice features for declarative setup, user environment management boils down to terminal commands for "install package X, remove package Y". The mentioned home-manager seems more of an awkward hack than a good solution in my view. It builds up a parallel package repository that you have to use besides the actual packages, and requires a lot of additional work if you want to customize something. In my understanding (possibly incorrent?) it is also not actually immutable, but just dumps down files into $HOME, losing the most interesting aspect of Nix. In the end I ditched it and stuck to my Ansible setup. Nix is a great approach, and definitely worth a look, if you can stomach the other downsides (see below). But right now I would only recommend it for deterministic server builds or isolated dev environments, not for managing you main setup. * Problems: - There is plenty of documentation, but it is often incoherent, messy, missing important explanations, and it is generally very awkward to get a good insight and understanding of how all the parts fit together. - The language... it is full of confusing oddities; clearly something that has grown peace by piece. Switching to something more coherent like Gluon (also functional, https://github.com/gluon-lang/gluon https://github.com/gluon-lang/gluon) would seem like a better approach to me. - Packages: The quality can be very hit and miss. I discovered several that are written poorly. Plenty are also outdated/unmaintained. But: considering the niche nature of Nix, the amount of packages is actually quite impressive.
- oever 7y ago
  The documentation is not much aimed on a developer workflow. The `shell.nix` files make it easy to place the environment setup in your repository. The file contains the list of packages that you need and you can make these packages available in just one shell by calling `nix-shell`. Here's an example of a `shell.nix` file: with import <nixpkgs> {}; stdenv.mkDerivation { name = "cv-env"; buildInputs = [ libxslt gnumake openjdk entr ]; }
  - the_duke 7y ago
    I tried to do this, but I ran into way too many problems. Each approach I tried failed because of some limitation that made the whole thing awkward or pointless. (like symlinking immutable config files into $HOME) This admittedly might have been exacerbated by my shallow understanding.
hrchak 7y ago
I have very similar setup https://github.com/dejanr/dotfiles https://github.com/dejanr/dotfiles it was inspired by https://github.com/peel/dotfiles https://github.com/peel/dotfiles and few other repositories. Also i still symlink some stuff like stow is doing, but with few shell scripts. The main difference is that my dotfiles are not start with '.'. Idea is to move everything to nix, so that when you rollback, you rollback your dotfiles as well. What i wish maybe, is that i used home manager but that some future focus.
gbrown_ 7y ago
My $HOME is a git repo for my dotfiles, with a .gitignore containing just "*". Simple, zero abstractions, no need for additional management.
- bbmario 7y ago
  Same here. New machine? Add a remote, checkout master.
- josephscott 7y ago
  I've recently started using yadm, which is a light abstraction on top of git. One big reason - "Alternate Files" support - which makes it easy to have MacOS and Linux binaries for the same tools, along with the rest of my shell setup, in one Git repo.
- deepaksurti 7y ago
  Further, you can create a bare git repo and make $HOME it's working tree. More details here [1]. [1] https://news.ycombinator.com/item?id=11071754 https://news.ycombinator.com/item?id=11071754
- dnpp123 7y ago
  funny enough, this technique is also described here : https://drewdevault.com/2019/12/30/dotfiles.html https://drewdevault.com/2019/12/30/dotfiles.html
tomerbd 7y ago
stay simple, simple dot files, don't create overkill work for yourself so you don't need to manage your dot files.
streb-lo 7y ago
I for one am waiting for systemd homed.
- jacobush 7y ago
  As always with anything about systemd, it's impossible to know if it's satire without looking at the source code. Sometimes, not even then.

122 points by devhugo 7y ago

I just clone my dotfile repo from github into ~/darkrc and include the config files I want on each system, so my ~/.bashrc will have a "source $HOME/darkrc/bashrc" at the end, ~/.config/ranger/rc.conf will have "source ~/darkrc/ranger.conf", etc.

devhugo 7y ago
That's certainly one option. The unique thing about dotfiles is that everyone has a different 'best solution'. The setup outlined in my post has the advantage of being highly configurable and programmable. However, for some people it might make more sense to use a plain git repo with symlinks as installing Nix on all their devices could be a nonstarter. I'm curious, what do you use to manage tools that don't have a `source $SOME_PATH` option. Do you symlink?
- pletnes 7y ago
  I used to symlink and have a simple dotfiles repo, but this forces you to have exactly identical rc files. Different computers simply need different setups, so I started with ansible and a few playbooks running locally.
  - roryrjb 7y ago
    This was posted recently https://drewdevault.com/2019/12/30/dotfiles.html https://drewdevault.com/2019/12/30/dotfiles.html, but I actually liked the idea of using uname, hostname etc in constructing $PATH and even though I was already using git to track my dotfiles I adapted some parts of my setup like Drew describes and made $HOME a git repo itself ignoring everything by default. Works quite well across different OSs, machines and shells.
- DarkWiiPlayer 7y ago
  Generally speaking, I avoid those tools. One example where this happens is rifle; in that case I just have a symlink. Alternatively, one could also just get a standalone C preprocessor and add a git hook to recompile files whenever you commit/pull some new changes.

tyrion 7y ago

Nice post, thanks for sharing. I currently use vcsh and myrepos and they work great for me. Now that I switched to Nixos maybe I could give home-manager a try. I wrote about my approach here in case you are interested ( https://germano.dev/dotfiles/ https://germano.dev/dotfiles/ )

devhugo 7y ago
Interesting. Home manager will enable you to manage your dotfiles. The more interesting proposition comes from Nix. I've absolutely loved using it in general and run NixOS by choice as my desktop OS. The great thing about using Nix and Home Manager to manage dotfiles is that your configuration is defined in a programming langauge. You have broad scope to control things based on whatever environment you are deploying the files to. It's a really powerful solution, it just takes a bit more time than some other dotfile systems. Give Home Manager a go if you have time to tinker, and if you have questions feel free to contact me through my email on my homepage.

trevorrr 7y ago

Would prefer GNU stow for simplicity. https://www.gnu.org/software/stow/ https://www.gnu.org/software/stow/

codebeaker 7y ago
GNU Stow is _great_ for this. I have the following in my dotfiles dir: [~/code/dotfiles]$ tree -a -R -L 2 ├── aws │ └── .aws ├── git │ ├── .gitconfig │ └── .gitignore_global ├── .gitignore ├── .gitmodules ├── gpg │ └── .gnupg ├── README ├── ssh │ └── .ssh ├── tmux │ ├── .tmux │ └── .tmux.conf ├── vim │ ├── .viminfo │ └── .vimrc └── zsh ├── .oh-my-zsh └── .zshrc I can then stow any of these into my home dir with: $cd ~/code/dotfiles $ stow -t $HOME git That sets up a link from all the files in my home dir like: .gitconfig -> code/dotfiles/git/.gitconfig
devhugo 7y ago
I've looked at and read about other's experiences with stow in the past. I'm uncertain about this so please correct me where I am wrong, but the issues I see with stow are: 1. It's somewhat dated/may have a tail of legacy features 2. I'm unsure of it's value beyond of what can be provided via the Git Bare Repo solution linked in the intro of my post. 3. More importantly, it's not a programmable solution where you can override default files based on the current system. The main value proposition I see in my system is that I can define a single default configuration for, say, my terminal Alacritty, and override the configuration where necessary based on either my user, machine or role. Nix is a programming language, so I essentially have my system configuration managed via a programming language and can control things with a great level of detail.
- padthai 7y ago
  I use Stow, it is simple and only does a few things, but for a lot of users like me it is more than enough: 1. Probably it will not receive more features any time soon. 2. You can have several configurations and mix them, also it makes very easy to adopt changes from the current system and/or rollback changes. 3. No, it is not programmable, but you can have several folder for different systems and configurations. I for example have a folder called unix for all *nix systems, other called x11 for x11 programs, darwin for macOS, etc. You could do the same with roles. If you want really fine grained control over machine/user/role, it is not enough, and it does not take into account package managing at all. I use a mix of Stow/Ansible for Desktops and HashiCorp/Ansible for the `cattle`. Nix is more powerful than my setting, but I still need to evaluate if it is flexible enough for the orgs I work with.

the_duke 7y ago

I tried out Nix recently, with the intention of using it to get declarative management of my user account. I discovered too late that Nix basically has no support for this. While NixOS has some very nice features for declarative setup, user environment management boils down to terminal commands for "install package X, remove package Y". The mentioned home-manager seems more of an awkward hack than a good solution in my view. It builds up a parallel package repository that you have to use besides the actual packages, and requires a lot of additional work if you want to customize something. In my understanding (possibly incorrent?) it is also not actually immutable, but just dumps down files into $HOME, losing the most interesting aspect of Nix. In the end I ditched it and stuck to my Ansible setup. Nix is a great approach, and definitely worth a look, if you can stomach the other downsides (see below). But right now I would only recommend it for deterministic server builds or isolated dev environments, not for managing you main setup. * Problems: - There is plenty of documentation, but it is often incoherent, messy, missing important explanations, and it is generally very awkward to get a good insight and understanding of how all the parts fit together. - The language... it is full of confusing oddities; clearly something that has grown peace by piece. Switching to something more coherent like Gluon (also functional, https://github.com/gluon-lang/gluon https://github.com/gluon-lang/gluon) would seem like a better approach to me. - Packages: The quality can be very hit and miss. I discovered several that are written poorly. Plenty are also outdated/unmaintained. But: considering the niche nature of Nix, the amount of packages is actually quite impressive.

oever 7y ago
The documentation is not much aimed on a developer workflow. The `shell.nix` files make it easy to place the environment setup in your repository. The file contains the list of packages that you need and you can make these packages available in just one shell by calling `nix-shell`. Here's an example of a `shell.nix` file: with import <nixpkgs> {}; stdenv.mkDerivation { name = "cv-env"; buildInputs = [ libxslt gnumake openjdk entr ]; }
- the_duke 7y ago
  I tried to do this, but I ran into way too many problems. Each approach I tried failed because of some limitation that made the whole thing awkward or pointless. (like symlinking immutable config files into $HOME) This admittedly might have been exacerbated by my shallow understanding.

hrchak 7y ago

I have very similar setup https://github.com/dejanr/dotfiles https://github.com/dejanr/dotfiles it was inspired by https://github.com/peel/dotfiles https://github.com/peel/dotfiles and few other repositories. Also i still symlink some stuff like stow is doing, but with few shell scripts. The main difference is that my dotfiles are not start with '.'. Idea is to move everything to nix, so that when you rollback, you rollback your dotfiles as well. What i wish maybe, is that i used home manager but that some future focus.

gbrown_ 7y ago

My $HOME is a git repo for my dotfiles, with a .gitignore containing just "*". Simple, zero abstractions, no need for additional management.

bbmario 7y ago
Same here. New machine? Add a remote, checkout master.
josephscott 7y ago
I've recently started using yadm, which is a light abstraction on top of git. One big reason - "Alternate Files" support - which makes it easy to have MacOS and Linux binaries for the same tools, along with the rest of my shell setup, in one Git repo.
deepaksurti 7y ago
Further, you can create a bare git repo and make $HOME it's working tree. More details here [1]. [1] https://news.ycombinator.com/item?id=11071754 https://news.ycombinator.com/item?id=11071754
dnpp123 7y ago
funny enough, this technique is also described here : https://drewdevault.com/2019/12/30/dotfiles.html https://drewdevault.com/2019/12/30/dotfiles.html

tomerbd 7y ago

stay simple, simple dot files, don't create overkill work for yourself so you don't need to manage your dot files.

streb-lo 7y ago

I for one am waiting for systemd homed.

jacobush 7y ago
As always with anything about systemd, it's impossible to know if it's satire without looking at the source code. Sometimes, not even then.