treewide: completely remove types.loaOf

[rnhmjoj]

Motivation for this change

Finalise the removal of loaOf, started with #63103.
See also #77189 (comment).

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Determined the impact on package closure size (by running nix path-info -S before and after)
• Ensured that relevant documentation is up to date
• Fits CONTRIBUTING.md.

[worldofpeace]

Why don't we turn the warning in the type into something fatal to help people out?
Also mention in the release notes that it is now removed entirely?

[infinisil]

Also: While the warning mentioned that loaOf is deprecated, it only triggered when a list was assigned to it. So naturally the next step is to only remove support for assigning lists, and add a warning for loaOf being used itself. So something like this:

{
  loaOf = lib.warn "loaOf is deprecated blabla..." attrsOf;
}

[rnhmjoj]

Uhm, it looks like changing options to attrsOf broke the manual, for some reason.

[infinisil]

Option references in docbook are:

• opt-foo._.bar when foo is listOf (submodule ..)
• opt-foo._name_.bar for attrsOf (submodule ..)
• opt-foo._name__.bar for loaOf (submodule ..)

This is why the manual fails, the references need to be changed from _name__ to _name_

[rnhmjoj]

Thank you, done. I don't know how the Nixos options integration in docbook happen, so is there a file that needs to be updated for the removal? I couldn't find any more references to loaOf.

[infinisil]

No idea either, haven't looked into it

[jtojnar]

We replace the ? in ids for _ here:

nixpkgs/nixos/lib/make-options-doc/options-to-docbook.xsl

Line 23 in 7e545bd

<xsl:variable name="id" select="concat('opt-', str:replace(str:replace(str:replace(str:replace(attr[@name = 'name']/string/@value, '*', '_'), '&lt;', '_'), '>', '_'), '?', '_'))" />

The id just comes from the option name itself IIRC.

[rnhmjoj]

@jtojnar, sorry but I understand very little of what's going on in that file. I still don't see anything related to loaOf in it, what should be changed?

[jtojnar]

We can drop the outermost replace if no other type adds ? to the generated option name lika loaOf did in getSubOptions.

[rnhmjoj]

Ok, I think I get it. It's because loaOf uses <name?> as a placeholder.
Yes, it seems no other type does this and the manual builds, so it should be safe to remove.

[infinisil]

LGTM

[cole-h]

Diff LGTM, thanks!

[rnhmjoj]

Thank you all!

[worldofpeace]

Absolutely, and I return the thanks ten fold ✨