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.

  • dbx12@programming.devEnglish
    4·
    2 months ago

    I basically know nothing about NixOS, but name spacing is usually a good idea to avoid conflicts / shadowing in config files.

  • rutrum@lm.paradisus.dayEnglish
    3·
    2 months ago

    I think this is good idea. If the modules/options you are writing are for internal use, and not expected to be shared with the wider community, then this is great. I should incorporate this in my own config, but I dont know if this is common practice.

  • QuizzaciousOtter@lemm.eeEnglish
    1·
    2 months ago

    I’m currently learning NixOS myself and was wondering about the same thing. I’m definitely leaning towards namespacing but I would like to hear an expert’s opinion.

    Also, just a question. Are you planning to expose all your configuration modules via custom options? When I’m looking at other people’s configs I feel like the most popular approach is to enable modules just by importing them. I really like the idea of having custom options for everything but it’s additional work and complexity and I can’t decide if it’s worth the effort.

    • anon2963OPEnglish
      2·
      2 months ago

      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.enable option, and then hides the entire contents of module1 behind a lib.mkIf options.module1.enable

      https://youtu.be/vYc6IzKvAJQ?t=147

      • QuizzaciousOtter@lemm.eeEnglish
        2·
        2 months ago

        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!