various: remove by-name overrides

[qweered]

Continuation of #469771, resurrection of #453948

Things done

• Built on platform:
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• Tested, as applicable:
  • NixOS tests in nixos/tests.
  • Package tests at passthru.tests.
  • Tests in lib/tests or pkgs/test for functions and "core" functionality.
• Ran nixpkgs-review on this PR. See nixpkgs-review usage.
• Tested basic functionality of all binary files, usually in ./result/bin/.
• Nixpkgs Release Notes
  • Package update: when the change is major or breaking.
• NixOS Release Notes
  • Module addition: when adding a new NixOS module.
  • Module update: when the change is significant.
• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other READMEs.

---

Add a 👍 reaction to pull requests you find important.

[SigmaSquadron]

Haven't reviewed all changes, but some preliminary notes:

• I feel like we really should avoid the { ... }@args pattern. It's complex, difficult to understand for new maintainers, and there's really no good reason to have it when we can just have luajit in the list of function inputs.
• Pinning dependencies like stormlib to older versions will likely have adverse security consequences.

[qweered]

I removed @args pattern. About pinning dependencies we really don't have better way to handle them, i know that focus of @NixOS/nixpkgs-core is to remove and then disallow by-name overrides

[gepbird]

Thanks for picking this up!

I went through the whole diff except glib as I'm out of time now, mostly looks good. Big thanks for splitting up the commits per package, those were easier to review than the various: commits. There were a few unrelated changes like rec -> finalAttrs, with libs.platforms removal or removing outdated overrides as suggested previously which is fine, but I think you could keep the scope a little narrower next time.

[emilazy]

AFAICT, this PR does not address the fundamental issues caused by current by-name limitations around sometimes producing unusable override interfaces (e.g. in the case of conditional stdenvs) that led to @wolfgangwalther’s original PR being abandoned, right?

• I feel like we really should avoid the { ... }@args pattern. It's complex, difficult to understand for new maintainers, and there's really no good reason to have it when we can just have luajit in the list of function inputs.

Avoiding it produces the worse outcome where you have a load‐bearing foo' but can still refer to the non‐overridden foo later in the package, as well as resulting in more code churn.

[qweered]

for { ... }@args or foo' problem we have rfc NixOS/rfcs#192 and implementation #464396

[mdaniels5757]

Rebased, which dropped the following commits: bc61ec4, 439778e, 5a635e4, a122428, 8561b04, 2e6967b

[mdaniels5757]

Just to help keep things straight:

• factorio: use explicit default values, remove override in all-packages.nix #484585, {vanillatd,vanillara}: use explicit default values, remove override in all-packages.nix #484586, and element-web: use explicit default values, remove override in all-packages.nix #484588 together are 76e1942
• dbeaver-bin: use scopes as arguments, remove all-packages.nix override #484590, kitty: use scopes as arguments, remove all-packages.nix override #484591, monado: use scopes as arguments, remove all-packages.nix override #484592, rescript-language-server: use scopes as arguments, remove all-packages.nix override #484594, vtfedit: use scopes as arguments, remove all-packages.nix override #484596 together are 06f290a

[mdaniels5757]

@qweered I guess the only things that haven't been split are c292e79 and b3ce16e.

I think c292e79 should probably be split up to be one PR for package. That way, each packages' maintainers can decide how they'd like to remove their all-packages.nix override, and this doesn't block the other packages. Would you mind splitting this one up and making those PRs? (In case you didn't already know about it: git add -p is your friend :) )

b3ce16e should be its own PR too, I think. That one is easy, but I don't want to make the PR without reading the diff, and I don't want to read all that... :)

[gepbird]

b3ce16e should be its own PR too, I think. That one is easy, but I don't want to make the PR without reading the diff, and I don't want to read all that... :)

That diff isn't that scary after you hide whitespace (I learned it from @qweered in #474456 (comment)).

[qweered]

every commit from this brach has been splitted into separate pr