Passthru-attributes

[]{#var-stdenv-passthru} []{#special-variables}

As opposed to most other mkDerivation input attributes, passthru is not passed to the derivation's builder executable. Changing it will not trigger a rebuild – it is "passed through". Its value can be accessed as if it was set inside a derivation.

Note

passthru attributes follow no particular schema, but there are a few conventional patterns.

Example

Setting and accessing `passthru` attributes

{ stdenv, fetchGit }:
let
  hello = stdenv.mkDerivation {
    pname = "hello";
    src = fetchGit { /* ... */ };

    passthru = {
      foo = "bar";
      baz = {
        value1 = 4;
        value2 = 5;
      };
    };
  };
in
hello.baz.value1

Common `passthru`-attributes

Many passthru attributes are situational, so this section only lists recurring patterns. They fall in one of these categories:

Global conventions, which are applied almost universally in Nixpkgs.

Generally these don't entail any special support built into the derivation they belong to. Common examples of this type are passthru.tests and passthru.updateScript.

Conventions for adding extra functionality to a derivation.

These tend to entail support from the derivation or the passthru attribute in question. Common examples of this type are passthru.optional-dependencies, passthru.withPlugins, and passthru.withPackages. All of those allow associating the package with a set of components built for that specific package, such as when building Python runtime environments using (python.withPackages)[#python.withpackages-function].

Attributes that apply only to particular build helpers or language ecosystems are documented there.

`passthru.tests`

[]{#var-meta-tests}

An attribute set with tests as values. A test is a derivation that builds when the test passes and fails to build otherwise.

Run these tests with:

$ cd path/to/nixpkgs
$ nix-build -A your-package.tests

Note

The Nixpkgs systems for continuous integration Hydra and nixpkgs-review don't build these derivations by default, and (@ofborg) only builds them when evaluating pull requests for that particular package, or when manually instructed.

Package tests

[]{#var-meta-tests-packages}

Besides tests provided by upstream, that you run in the checkPhase, you may want to define tests derivations in the passthru.tests attribute, which won't change the build. passthru.tests have several advantages over running tests during any of the standard phases:

They access the package as consumers would, independently from the environment in which it was built
They can be run and debugged without rebuilding the package, which is useful if that takes a long time
They don't add overhead to each build, as opposed checks added to the distPhase, such as versionCheckHook.

It is also possible to use passthru.tests to test the version with testVersion, but since that is pretty trivial and recommended thing to do, we recommend using versionCheckHook for that, which has the following advantages over passthru.tests:

If the versionCheckPhase (the phase defined by versionCheckHook) fails, it triggers a failure which can't be ignored if you use the package, or if you find out about it in a nixpkgs-review report.
Sometimes packages become silently broken - meaning they fail to launch but their build passes because they don't perform any tests in the checkPhase. If you use this tool infrequently, such a silent breakage may rot in your system / profile configuration, and you will not notice the failure until you will want to use this package. Testing such basic functionality ensures you have to deal with the failure when you update your system / profile.
When you open a PR, ofborg's CI will run passthru.tests of packages that are directly changed by your PR (according to your commits' messages), but if you'd want to use the @ofborg build command for dependent packages, you won't have to specify in addition the .tests attribute of the packages you want to build, and no body will be able to avoid these tests.

For more on how to write and run package tests for Nixpkgs, see the testing section in the package contributor guide.

NixOS tests

[]{#var-meta-tests-nixos}

Tests written for NixOS are available as the nixosTests argument to package recipes. For instance, the OpenSMTPD derivation includes lines similar to:

{ nixosTests, ... }:
{
  # ...
  passthru.tests = {
    basic-functionality-and-dovecot-integration = nixosTests.opensmtpd;
  };
}

NixOS tests run in a virtual machine (VM), so they are slower than regular package tests. For more information see the NixOS manual on NixOS module tests.

`passthru.updateScript`

[]{#var-passthru-updateScript-command} []{#var-passthru-updateScript-set-command} []{#var-passthru-updateScript-set-attrPath} []{#var-passthru-updateScript-set-supportedFeatures} []{#var-passthru-updateScript-env-UPDATE_NIX_NAME} []{#var-passthru-updateScript-env-UPDATE_NIX_PNAME} []{#var-passthru-updateScript-env-UPDATE_NIX_OLD_VERSION} []{#var-passthru-updateScript-env-UPDATE_NIX_ATTR_PATH} []{#var-passthru-updateScript-execution} []{#var-passthru-updateScript-supported-features} []{#var-passthru-updateScript-commit} []{#var-passthru-updateScript-commit-attrPath} []{#var-passthru-updateScript-commit-oldVersion} []{#var-passthru-updateScript-commit-newVersion} []{#var-passthru-updateScript-commit-files} []{#var-passthru-updateScript-commit-commitBody} []{#var-passthru-updateScript-commit-commitMessage} []{#var-passthru-updateScript-example-commit}

Nixpkgs tries to automatically update all packages that have an passthru.updateScript attribute. See the section on automatic package updates in the package contributor guide for details.

Passthru-attributes

Setting and accessing passthru attributes

Common passthru-attributes

passthru.tests