I have started using NixOS recently and I am just now creating conventions to use in my config.
One big choice I need to make is whether to include a unique identifier as the most significant attribute in any options that I define for my system.
For example:
Lets say I am setting up my desktop so that I am easily able to switch between light and dark modes system-wide. Therefore, I create the boolean option:
visuals.useDarkMode
Lets say I also want to toggle on/off Tor and other privacy technologies all at once easily, so I create the boolean:
usePrivateMode
Although these options do not do related things, they are still both custom options that I have made. I have the first instinct to somehow segregate them from the builtin NixOS options. Let’s say my initials are “RK”. I could make them all sub-attributes of the “RK” attribute.
rk.visuals.useDarkMode
rk.usePrivateMode
I feel like this is either a really good idea or an antipattern. I would like your opinions on what you think of it and why.
Note: I haven’t tested this yet, but I don’t see any reason why it wouldn’t.
You can have the best of both worlds by importing modules and then enabling/disabling them with config options.
The idea is that every single module, whether you want to be able to toggle them on/off or not, gets imported into your configuration.nix. For options that you want to permanently be enabled, there is no more work to do. For options or groups of options that you want to be toggleable on/off, you put them behind a
lib.mkIf.In the following video, Vimjoyer essentially makes an option that enables/disables an entire module, even though it is already imported. He creates an
options.module1.enableoption, and then hides the entire contents of module1 behind alib.mkIf options.module1.enablehttps://youtu.be/vYc6IzKvAJQ?t=147
Right, in the simplest case it’s a single option declaration and a single
lib.mkIf. I was probably overthinking the complexity. I will probably go with this approach.Thanks for the answer and happy nixing!