How do you organize dotfiles?

Well, I’m get used to usual dotfiles, like linking them, or making a huge script to do this for me (GitHub - zoedsoupe/nixnad: Config files to set up a Software development workstation!) but with Nix all is kinda different for me.

Firstly, we define the core on /etc, so it’s a root owned folder. How I could link this to VCS?

Secondly, how you define what is configured by Nix and what goes into stanstard dotfiles?

Like, everything you can you code in Nix or stills using dotfiles?

My case: I decided to mantain some huge configs, like Xmonad, on your respectively config files, as haskell files and no Nix. However, some minor configs like picom and fish I liked to write in Nix.

What’s your case?

As a rule of thumb I try to keep the system small and free of cruft.

I want it to be re-installable within 30 minutes assuming my own internet connection.

I do not configure what I do not install from the system, though what I install as part as the system also gets configured in the system config. I try to avoid manual configuration through stray files as much as I can.

On top of that I have user configuration, which partially depends on system capabilities and at the end is managed by home-manager. Again I try to avoid configuration through stray files as much as I can.

For my user I do not really care if it has huge build times, as I usually can already work in some way at least while the user closure builds and applies for the first time. A full rebuild can take several hours due to using Emacs with jit from the Emacs overlay.

Both, user and system configuration are flakyfied in a single repository (did the join of 2 separate repos yesterday, still not fully complete), but I strictly separate the concern between user and system config and I am not a friend of using home manager as a module, as that clashes with small system principle and also makes it impossible to roll back individually.

2 Likes

Interesting, what brought you to eventually join them? I initially started out in one, but at some point split at the system/user boundary for privacy reasons. The systems have some information about other users and dependents. I thought it’s easier to add or manage those in the bigger private space instead of maintaining them behind or even across the privacy boundary. Now I’m considering the privacy-oriented split again (although it would be tedious), to be able to better communicate educational aspects - such as for this question.

Nix takes care of that. That’s what I think is a major part of the beauty: you can define what it’s about and don’t need to care much how it’s done, and organize your configuration as you see fit.

As for @NobbZ all of my system and user environment is managed through NixOS and home-manager respectively. They place the required files where they belong. Finally, I don’t even have to know! I do use tool-specific formats where appropriate. Xmonad is a good example, but also init.vim. Many tools have excellent support from home-manager, so I don’t need to remember or read up all their various syntaxes.

The configurations are obviously version controlled. Just recently I had to switch back to netatalk on my NAS for a certain task, because samba is just too slow. Checked out the old config snippet, rebuilt, finished working, checked back and rebuilt again. Thank you all, community, stuff like this is why there is no going back to anything else.

Mostly because it is much easier to have them share the same “pins”.

My previous approach using inputs.nixpkgs.follows = "system/nixpkgs" already introduced a coupling between both, that I considered unfortunate, especially as I didn’t use anything from the system flake, except for its inputs to pin…

I see. That’s exactly where my setup has a little kink, too, although it did not really bother me yet.

So cool configs! I decided to concentrate all my config into /etc directory with home-managerintegrated and is working fine that way once I’ve only one machine and do not change configs very frequently.