Override derivation with overrideAttrs: any way to handle `let ... in`?

I understand that overrideAttrs is used to override the arguments to mkDerivation.

I often face the challenge that package definitions put a lot of stuff in let ... in blocks outside the mkDerivation body.

This is a PITA if I want to just override e.g. one env var in a wrapper, without copying everything verbatim in my new expression.

Is there any way to handle such cases?

(My current example is I want to add QT_SCALE_FACTOR = 2 or GDK_SCALE) to either the Exec in the .desktop file or add it to the wrapper for some apps, e.g. this one or this one)

1 Like

Not really. Nix offers no such mechanism so it would need to be supported in Nixpkgs like overrideAttrs is.

Alternately, we can use the existing override or overrideAttrs mechanisms if we structure the derivation cleverly:

  • overrideAttrs can be used with passthru and finalAttrs (example)
  • override can be combined with scope (example collapsed in details element in this comment)

Though there are no conventions at the moment.

Related discussions:

2 Likes

Thanks, good info! I was afraid of that, basically derivation authors seem to have “too much freedom” and ideally would consider overridability more. Admittedly I haven’t fully grasped the deeper finesse of those patterns myself yet, but I’ll try and learn too :wink:

As a side note, maybe it could be of interest to try to standardise and document a number of package arguments (such as hidpi for instance, which could be beneficial in my examples to override badly-behaved (binary distributed) programs), but that would start the “USE-flags” argument allover again. (I stand by my position that a set of carefully chosen and standardised “USE-flags” for nixpkgs would greatly improve UX/DX.)