[Nix-dev] Best Practices on Modularizing Configuration.nix?

[Mark Gardner]

Now that I am putting NixOS on more and more machines, I would like to
modularize and share parts of the config to maximize reuse and ensure
uniformity. My approach is to consider the sub-config files as traits or
roles and combine them together to create configuration.nix for a specific
machine, like this:

- cfg/common.nix  # common config
- cfg/desktop.nix  # xorg and related
- cfg/laptop.nix  # related to all laptops
- cfg/work.nix  # work location related
...
- cfg/mylaptop.nix  # specific laptop related

I import from these to make up configuration.nix. For example, on my
laptop, configuration.nix contains:

---
{ config, pkgs, ... }:

{
  imports =
    [
      ./hardware-configuration.nix
      ./cfg/mylaptop.nix
      ./cfg/common.nix
      ./cfg/desktop.nix
      ./cfg/laptop.nix
      ./cfg/work.nix
    ];
}
---

So far, this seems like a good approach. Except that each machine has its
own configuration.nix that I would like to keep in the git repository too
but of course I can't have different top level files with the same name. To
solve this, I could moved the current configuration.nix inside of cfg (as
cfg/mylaptop.cfg.nix perhaps) or merge with the existing cfg/mylaptop.nix
then making configuration.nix a symlink to it. That way the only thing to
do by hand is create the symlink to select a particular configuration. Is
this reasonable? Is there a better way to do it?

How do you modularize your configuration and put it into a repo such that
you can easily create a configuration for a new machine (and put it in the
repo too) without a lot of hand work?

Mark
-- 
Mark Gardner
--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.science.uu.nl/pipermail/nix-dev/attachments/20170227/174bf262/attachment.html>