some overrideDerivation cleanups

[infinisil]

These four top-level packages were the only ones that didn't have the
meta.position attribute automagically set. This commit fixes this.

Motivation for this change

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
• 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 nox --run "nox-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Fits CONTRIBUTING.md.

---

[grahamc]

FWIW: https://github.com/NixOS/nixpkgs/pull/41165/files#r193124185 but I don't know why.

[infinisil]

Maybe he meant both overrideAttrs and overrideDerivation? No idea, but I won't let it worry me without an explanation :)

The docs certainly favor overrideAttrs: https://nixos.org/nixpkgs/manual/#sec-pkg-overrideDerivation

[dezgeg]

Yes, I believe this warning in the linked manual chapter applies to both:

Warning: Do not use this function in Nixpkgs as it evaluates a Derivation before modifying it, which breaks package abstraction and removes error-checking of function arguments. In addition, this evaluation-per-function application incurs a performance penalty, which can become a problem if many overrides are used. It is only intended for ad-hoc customisation, such as in ~/.config/nixpkgs/config.nix.

[danbst]

It should be possible to not introduce overrideAttrs here:

luajit_2_0 = generic {
     version = "2.0.5";
     isStable = true;
     sha256 = "0yg9q4q6v028bgh85317ykc9whgxgysp76qzaqgq55y6jy11yjw7";
     meta = meta // {
      platforms = lib.filter (p: p != "aarch64-linux") meta.platforms;
 };

generic = { ..., meta ? meta }:
 stdenv.mkDerivation rec {
      inherit name version src meta;
....
;

overrideAttrs doesn't make this generative stuff cleaner IMO.

[andir]

I agree. @infinisil can you adjust it as shown by @danbst?

[danbst]

I see no harm in replacing lib.overrideDerivation to .overrideAttrs, that doesn't make situation "worse". The one that introduces can be rewritten to not introduce.

[andir]

I agree. @infinisil can you adjust it as shown by @danbst?

[infinisil]

Fixed that, but I couldn't use meta as the attribute in the top level, because apparently { meta ? meta }: ... tries to use the arguments meta for the default value, didn't know that (and it doesn't make any sense for it to be that way)!

[danbst]

oh right, forgot func args are implicilty rec

[dezgeg]

{ meta ? meta }: is pretty nonsensical indeed, but having e.g. { stdenv, enableFoo ? stdenv.isLinux }: is pretty useful.

[matthewbauer]

I don't think meta works with overrideAttrs. Can you confirm that the meta is still being applied? I thought you still had to do a union like with overrideDerivation.

[infinisil]

Does indeed work, the main reason I'm doing this PR is to have meta.position available. All other meta attributes work as well.

[matthewbauer]

Ok looks good then.