# Overriding {#chap-overrides}

Sometimes one wants to override parts of `nixpkgs`, e.g. derivation attributes, the results of derivations.

These functions are used to make changes to packages, returning only single packages. [Overlays](#chap-overlays), on the other hand, can be used to combine the overridden packages across the entire package set of Nixpkgs.

## <pkg>.override {#sec-pkg-override}

The function `override` is usually available for all the derivations in the nixpkgs expression (`pkgs`).

It is used to override the arguments passed to a function.

Example usages:

```nix
pkgs.foo.override {
  arg1 = val1;
  arg2 = val2; # ...
}
```

It's also possible to access the previous arguments.

```nix
pkgs.foo.override (previous: {
  arg1 = previous.arg1; # ...
})
```

<!-- TODO: move below programlisting to a new section about extending and overlays and reference it -->

```nix
import pkgs.path {
  overlays = [
    (self: super: {
      foo = super.foo.override { barSupport = true; };
    })
  ];
}
```

```nix
{
  mypkg = pkgs.callPackage ./mypkg.nix {
    mydep = pkgs.mydep.override {
      # ...
    };
  };
}
```

In the first example, `pkgs.foo` is the result of a function call with some default arguments, usually a derivation. Using `pkgs.foo.override` will call the same function with the given new arguments.

Many packages, like the `foo` example above, provide package options with default values in their arguments, to facilitate overriding.
Because it's not usually feasible to test that packages build with all combinations of options, you might find that a package doesn't build if you override options to non-default values.

Package maintainers are not expected to fix arbitrary combinations of options.
If you find that something doesn't work, please submit a fix, ideally with a regression test.
If you want to ensure that things keep working, consider [becoming a maintainer](https://github.com/NixOS/nixpkgs/tree/master/maintainers) for the package.

## &lt;pkg&gt;.overrideAttrs {#sec-pkg-overrideAttrs}

The function `overrideAttrs` allows overriding the attribute set passed to a `stdenv.mkDerivation` call, producing a new derivation based on the original one. This function is available on all derivations produced by the `stdenv.mkDerivation` function, which is most packages in the nixpkgs expression `pkgs`.

Example usages:

```nix
{
  helloBar = pkgs.hello.overrideAttrs (
    finalAttrs: previousAttrs: {
      pname = previousAttrs.pname + "-bar";
    }
  );
}
```

In the above example, "-bar" is appended to the pname attribute, while all other attributes will be retained from the original `hello` package.

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 `finalPackage` attribute which is equal to the result of `mkDerivation` or subsequent `overrideAttrs` calls.

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).