Hey folks, here’s the deal: I’ve setup my laptop to allow me to wipe/reinstall pretty easily. I erase/reformat my / partition while leaving my /home untouched. I then use a pretty extensive linux-bootstrap project I’ve massaged over the years to install specific packages.
I’m now seeing the value in Nix, and at a high level I’m wanting to do the following:
Migrate all my manual installs to use Nix nix-env – I assume migrating to Home Manager is probably warranted
Once I’m comfortable with that, wipe my / and install nix fresh
Here are my questions:
Should I go ahead and use a flake for my home manager setup? I want to have something standardized for when I setup new machines, but I don’t quite grok this yet.
I also tend to use dotbare to manage my dot files. Should this be migrated into home manager too?
In short, how should I setup this first step in such a way I can leverage it later?
In short, you can but expect changes at some point.
home-manager can fully replace GNU/Stow and similar tools and I would highly recommend it.
The nice thing is that when you have the package defined in home-manager as well, the config can live right next to it.
Like for my Emacs config, where the config files live right next to the home-manager config and get symlinked to the correct place by home-manager:
BTW. for a nice setup you probably don’t want to use nix-env but rather define everything in home-manager.
Depends, migrating to flakes later on is usually not much work unless you have a very big config which loads files from all over the place.
I wouldn’t recommend that. home-manager is inflexible and changing settings in dotfiles becomes suddenly hard and is everytime combined with some waiting. A good dotfiles manager is usually a better fit to manage dotfiles. Especially when you only have NixOS systems it often feels redundant and gets dragged along. Having everything in NixOS on a single user machine is just so much easier and more straight forward.
Translating my existing config into home-manager didn’t feel worth the time especially after I looked at the ssh_config module which wanted me to write constraints for my hosts to define the order while I just wanted a sorted list. Just copy pasting the config into extraConfig is also not improving things, then I can just keep my dotfiles repo.
I agree with @Nebucatnetzer, flakes are what everyone uses this days despite them being “unstable”.
The linked thread is a good read if you’re interested in the details or reasons.
I would advise against using nix-env since declarative configurations are easier to manage.
Regarding dotfiles,
If you’re gonna go into the Nix rabbit hole using home-manager is just a logic step, convenience and a unified config interface + rollbacks et all.
I agree it can be annoying at times.
However you can easily remove a home-manager symlink, hack around, update the config and remove the file and after a “rebuild” it regenerates the link.
Or another workaround I use for Emacs is that I only symlink the init.el file which then loads various files from ~/.nixos/home-manager/programs/emacs/emacs.d/. The files in emacs.d then aren’t read only so I can easily hack on the config but on a new system home-manager makes sure that the symlink exists like any other dot file manager. With the exception that I don’t need an additional software.
I don’t agree with this, home-manager has additional options for easy configuration. Not all of them are available in NixOS. In addition it’s a nice bonus that I can have my setup on other distros as well.
IMO it does but I reckon that subjective
The other option would be to just symlink the file in place and saving the need for another tool.
In the end it depends on the workflow/mindset.
I personally always forgot to update my dotfiles and they always lived a bit separated from my Ansible playbooks.
With NixOS and home-manager, everything lives in one place and it forces me to include changes beforehand. It can be annoying but this way I actually do it and all my systems are the same.
If I am constantly doing that then I might just edit the plain files and use a dotfile manager that is not in my way.
When managing programs which don’t want to managed declarative, looking at you plasma, it can be done with a dotfile managers, you just have a commit with some noise once in a while. Many programs expect to write into their config which is sometimes even a database and they are quite hard and cumbersome to manage with read only configs.
Also a good chunk of home-manager options are basic and just add a package and write some options into a file unlike some nixos options which configure a hundred lines of nginx config which is incredible value.
home-manager is only really great at one thing: manage nix-env declarative
Putting all your configs into it is IMO a dead end and if you are changing your dotfiles more often than once in a honeymoon it slows you down.
home-manager is only really great at one thing: manage nix-env declarative Putting all your configs into it is IMO a dead end and if you are changing your dotfiles more often than once in a honeymoon it slows you down.
I very strongly disagree. It’s absolutely correct that some applications play nicer with declarative config files than others, but it doesn’t have to be either/or.
The way I see it, there are 4 types of user config:
what hm needs to stay completely away from and where there is no point syncing/sharing config with other machines. Can’t think of any right now, but I left it here to cover all scenarios
what can be handled completely declaratively. git as an example.
what hm needs to stay away from but where symlinking things into place from a shared space works. filezilla as an example.
a combination of hm generated config that is merged with regular stateful config. This is what I do for plasma.
So to elaborate on the last item, there are certain plasma things I want be in sync such as baloo ignored directories (just one example of many), so I have hm create a plasma startscript that uses crudini to merge some settings into the config file. This way plasma can still do its thing but I have a way to ensure that some settings are applied everywhere.
I would say that using hm as a nix-env replacement is probably what I use it for the least.
But most importantly - knowledge base for the configuration. Being able to generate configuration and keeping copious notes/documentation makes things so much easier when revisiting things 9 months later.
If you’re just looking to get started and want to transition your tools to nix, I can really recommend creating a nix file and installing that directly with nix-env or nix profile.
Applications whose configuration is so incredibly complex that stow & co. simply fall short of being able to create syncable configs.
I think one of my main motivators for using nix/home-manager was ultimately using emacs.
I used use-package before, but it never produced predictable results (SSL verification issues when installing, package versions would mismatch, host binary versions would mismatch - breaking magit mostly, …).
Since switching to nix I actually have a working emacs config.
Firefox is also a big one, if you don’t want to use firefox-sync or such. This also lets you set all the hidden options, which is necessary when you use nvidia, and here home-manager helps again because you can limit some config to only devices with nvidia gpus…
Home-manager is absolutely excellent at slightly more complex configs intended to seamlessly work on multiple devices. The cost of having to wait a few seconds to apply a new config really doesn’t bother me that much, even when I’m changing a lot.
Ah yes, I do that too. And then being able to document why a setting was done in a certain way and adding toggles to set a group of settings if you are testing something out is just invaluable.
