Understanding `overrideDerivation` and Why `overrideAttrs` is Preferred

If only a one-argument function is written, the argument has the meaning of `previousAttrs`. Function arguments can be omitted entirely if there is no need to access `previousAttrs` or `finalAttrs`. ```nix { helloWithDebug = pkgs.hello.overrideAttrs { separateDebugInfo = true; }; } ``` In the above example, the `separateDebugInfo` attribute is overridden to be true, thus building debug info for `helloWithDebug`. ::: {.note} Note that `separateDebugInfo` is processed only by the `stdenv.mkDerivation` function, not the generated, raw Nix derivation. Thus, using `overrideDerivation` will not work in this case, as it overrides only the attributes of the final derivation. It is for this reason that `overrideAttrs` should be preferred in (almost) all cases to `overrideDerivation`, i.e. to allow using `stdenv.mkDerivation` to process input arguments, as well as the fact that it is easier to use (you can use the same attribute names you see in your Nix code, instead of the ones generated (e.g. `buildInputs` vs `nativeBuildInputs`), and it involves less typing). ::: ## <pkg>.overrideDerivation {#sec-pkg-overrideDerivation} ::: {.warning} You should prefer `overrideAttrs` in almost all cases, see its documentation for the reasons why. `overrideDerivation` is not deprecated and will continue to work, but is less nice to use and does not have as many abilities as `overrideAttrs`. ::: ::: {.warning} Do not use this function in Nixpkgs as it evaluates a derivation before modifying it, which breaks package abstraction. 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`. ::: The function `overrideDerivation` creates a new derivation based on an existing one by overriding the original's attributes with the attribute set produced by the specified function. This function is available on all derivations defined using the `makeOverridable` function. Most standard derivation-producing functions, such as `stdenv.mkDerivation`, are defined using this function, which means most packages in the Nixpkgs expression, `pkgs`, have this function.

This chunk concludes the discussion on `overrideAttrs`, reinforcing its utility for modifying attributes like `separateDebugInfo` and its superiority over `overrideDerivation` because it allows `stdenv.mkDerivation` to process arguments. It then introduces `overrideDerivation`, a function that creates a new derivation by overriding an existing one's attributes. However, `overrideDerivation` comes with strong warnings: * **Prefer `overrideAttrs`**: It's almost always the better choice due to greater flexibility, ease of use, and compatibility with `stdenv.mkDerivation`'s processing. * **Avoid in Nixpkgs**: `overrideDerivation` evaluates a derivation *before* modification, which breaks package abstraction and incurs performance penalties. It is strictly intended for ad-hoc customizations, such as those in `~/.config/nixpkgs/config.nix`, and should not be used for contributions to `nixpkgs` itself.