Deprecate types.loaOf

[rnhmjoj]

Motivation for this change

Fix issue #1800.

It turns out this is a lot of work: there are many instances of lists being used instead of sets.
The main culprits are users.users and environment.etc.
I think I have identified most of them but there are still some, moreover all this changes should be properly tested so I definitely need some help.

[infinisil]

If we want to deprecate this, there needs to be some deprecation warning for users. We can't just flip the switch and possibly break every second person's config. A good way to do that is to change the loaOf type to issue a warning when the list case is used, something like

Warning: You're assigning the list [ { name = "foo"; bar = <CODE>; ... } ... ] to
<option name>, which won't be supported in the future, use an attribute set like
{ foo = { bar = <CODE>; ... }; ... } instead. See
https://github.com/NixOS/nixpkgs/pull/63103 for more info.

[rnhmjoj]

Ok, I removed the attempts to replace loaOf with attrsOf and added a deprecation warning.
I don't know how to do something like that though

[infinisil]

Yeah this isn't what we need. The warning needs to go in the merge function. There one has access to all definitions, which can then be filtered to lists only, and for each of them one can print a warning as I showed in my comment. would be even neater to include the file and line where the user needs to do this change.

I generally think our error messages suck too much. It's not too difficult to make them better, especially with all the info the module system gives access to.

[rnhmjoj]

Ok, I'm working on it.

[rnhmjoj]

I took me a while but I think this should do it:

trace: warning: In file <nixpkgs/nixos/modules/services/misc/nix-daemon.nix>
a list is being assigned to the option config.users.users.
This will soon be an error as type loaOf is deprecated.
See https://git.io/fj2zm for more information.
Do
  users.users =
    { nixbld1 = {...}; nixbld2 = {...}; nixbld3 = {...}; ...}
instead of
  users.users =
    [ { name = "nixbld1"; ...} { name = "nixbld2"; ...} { name = "nixbld3"; ...} ...]

[rnhmjoj]

Uhm, no it doesn't work when the set is missing the name attribute.

[rnhmjoj]

I mean, it does but it's not pretty.

[rycee]

This will break the programs.ssh.matchBlocks option in Home Manager. That option allows use of list when the order matters and an attribute set as a convenience for users whose setup does not require a certain order.

I believe I originally had it as a listOf but got complaints that it was cumbersome for simple setups.

I don't particularly mind switching back to listOf since I, in principle, agree about the rationale for deprecating loaOf but thought I'd make a note of this use-case.

[rnhmjoj]

@rycee I don't know how home-manager works: are you somehow bound to nixos option types? Couldn't you simply define an equivalent loaOf for home-manager?