nordic-dev.net/nixpkgs
nordic-dev.net/nixpkgs
2
0
Fork 0
mirror of https://github.com/NixOS/nixpkgs.git synced 2024-11-22 23:13:19 +00:00
Code Issues Packages Projects Releases Wiki Activity

doc/using/overrides: Update for overlay style mkDerivation overrideAttrs

Browse Source
This commit is contained in:
Robert Hensing 2021-12-23 21:03:23 +01:00
parent d629ba27d9
commit 1bbb5a14c8
1 changed files with 6 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
doc/using/overrides.chapter.md
View File

@ -39,14 +39,18 @@ The function `overrideAttrs` allows overriding the attribute set passed to a `st
Example usage:
```nix
helloWithDebug = pkgs.hello.overrideAttrs (oldAttrs: rec {
helloWithDebug = pkgs.hello.overrideAttrs (finalAttrs: previousAttrs: {
separateDebugInfo = true;
});
```
In the above example, the `separateDebugInfo` attribute is overridden to be true, thus building debug info for `helloWithDebug`, while all other attributes will be retained from the original `hello` package.
The argument `oldAttrs` is conventionally used to refer to the attr set originally passed to `stdenv.mkDerivation`.
The argument `previousAttrs` is conventionally used to refer to the attr set originally passed to `stdenv.mkDerivation`.
The argument `finalAttrs` refers to the final attributes passed to `mkDerivation`, plus the `public` attribute which is the result of `mkDerivation` — the derivation or package.
If only a one-argument function is written, the argument has the meaning of `previousAttrs`.
::: {.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).