various: remove by-name overrides (part 2)

[mdaniels5757]

These are all taken from #474456. My hope is that this PR is easier to review, and contains fewer (or no!) objectionable changes.

Things done

• 0 rebuilds.
• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other READMEs.

[doronbehar]

I once heard an objection to this kind of changes that sounds similarly to this: "If someone has (e.g in the case of sile), a user that has an override such as sile.override { lua = lua5_4; }; will all of a sudden experience an error that will be unclear and force them to read the expression in Nixpkgs."

I think the above is a small price to pay, but is this a consensus?

[mdaniels5757]

I'm aware that that objection has been made in the past. (See also #469771, where Aleksanaa noted that others have made that objection, but where no objection was made.)

My opinion is:

• Yeah, it could be taken as a breaking change, that's why I'm not backporting it. :)
• The breaking change (if it even counts as one) is absolutely worth it: at a minimum, it will enable substantial simplification of nixpkgs-vet (Remove support for by-name overrides nixpkgs-vet#181), which will allow us to add support for other by-name directories in a clean and easy manner.

[mdaniels5757]

Also the error is actually pretty decent:

> nix-build -I nixpkgs=. --expr 'with (import <nixpkgs> {}); sile.override { lua = lua5_4; }'
error:
       … while calling a functor (an attribute set with a '__functor' attribute)
         at «string»:1:29:
            1| with (import <nixpkgs> {}); sile.override { lua = lua5_4; }
             |                             ^

       … while calling a functor (an attribute set with a '__functor' attribute)
         at /home/m/nixpkgs/lib/customisation.nix:194:20:
          193|           */
          194|           newArgs: makeOverridable f (overrideWith newArgs)
             |                    ^
          195|         );

       (stack trace truncated; use '--show-trace' to show the full, detailed trace)

       error: function 'anonymous lambda' called with unexpected argument 'lua'
       at /home/m/nixpkgs/pkgs/by-name/si/sile/package.nix:1:1:
            1| {
             | ^
            2|   lib,
       Did you mean lib?

[doronbehar]

Changes LGTM.

[doronbehar]

Good enough IMO.

[7c6f434c]

A bigger problem with Lua is that the interface stops making sense in some cases (LuaJIT is not a Lua 5.4 implementation, but a package might accept either as Lua). Although for many pins the pin is there exactly because you need an implementation of a specific version's behaviour.

(Here, for example, RenPy change is absolutely a sacrifice of semantics in the name of a minor refactoring)