Option such as apache web-services, pam rules, users, groups are not modular due to the usage of list of attribute sets. Using attribute sets instead of lists would foster modularity and avoid intrusive modification of NixOS. The side effect is that you cannot add unnamed attributes in case you don’t want to introduce modularity.

Another approach could be to accept both attribute set and list for option inputs where list are the unnamed version and where attribute set are the named version for the same option definition.

Submitted by Nicolas Pierron on 8 May 2011 at 23:00

In what sense are options like users and groups not modular? Different modules can add different users/groups.

I guess they could be attribute sets to allow different modules to set attributes for the same user/group, like users.extraUsers.foo.description = “Mr. Foo” in one module and users.extraUsers.foo.password = “bla” in another.

the modularity is inside the attribute set of the options. So as you describe, you can define the description in one module and the password in another (even if setting the password here is not safe)

But the main advantage is for either extending previous definitions such as adding a new group to a user or replacing a definition such as the home directory or the shell.

I added a new type of attribute which is “loaOf” and return an attribute set. The attribute set is the merge of attribute sets and lists (once transformed to an attribute set with attribute named automatically)

If the expected returned values is a list, then we can use the function attrValues to convert such attributes to a list.

One additional hidden issue remain, which is a conflict which exists between mkOrder and attribute set (and loaOf). This concern all “listOf” options which are using mkOrder to sort their content between modules.