Merge pull request #206742 from symphorien/nativeCheckInputs

  # ...

  checkInputs = [

  nativeCheckInputs = [

    postgresql

    postgresqlTestHook

  ];

something is exclusively a build-time dependency, then the dependency should be

included in `buildInputs`, but if it is (also) a runtime dependency, then it

should be added to `propagatedBuildInputs`. Test dependencies are considered

build-time dependencies and passed to `checkInputs`.

build-time dependencies and passed to `nativeCheckInputs`.

The following example shows which arguments are given to `buildPythonPackage` in

order to build [`datashape`](https://github.com/blaze/datashape).

    hash = "sha256-FLLvdm1MllKrgTGC6Gb0k0deZeVYvtCCLji/B7uhong=";

  };

  checkInputs = [ pytest ];

  nativeCheckInputs = [ pytest ];

  propagatedBuildInputs = [ numpy multipledispatch python-dateutil ];

  meta = with lib; {

```

We can see several runtime dependencies, `numpy`, `multipledispatch`, and

`python-dateutil`. Furthermore, we have one `checkInputs`, i.e. `pytest`. `pytest` is a

`python-dateutil`. Furthermore, we have one `nativeCheckInputs`, i.e. `pytest`. `pytest` is a

test runner and is only used during the `checkPhase` and is therefore not added

to `propagatedBuildInputs`.

test run would be:

```

  checkInputs = [ pytest ];

  nativeCheckInputs = [ pytest ];

  checkPhase = ''

    runHook preCheck

To filter tests using pytest, one can do the following:

```

  checkInputs = [ pytest ];

  nativeCheckInputs = [ pytest ];

  # avoid tests which need additional data or touch network

  checkPhase = ''

    runHook preCheck

Using the example above, the analogous `pytestCheckHook` usage would be:

```

  checkInputs = [ pytestCheckHook ];

  nativeCheckInputs = [ pytestCheckHook ];

  # requires additional data

  pytestFlagsArray = [ "tests/" "--ignore=tests/integration" ];

`unittestCheckHook` is a hook which will substitute the setuptools `test` command for a `checkPhase` which runs `python -m unittest discover`:

```

  checkInputs = [ unittestCheckHook ];

  nativeCheckInputs = [ unittestCheckHook ];

  unittestFlags = [ "-s" "tests" "-v" ];

```

    rm testing/test_argcomplete.py

  '';

  checkInputs = [ hypothesis ];

  nativeCheckInputs = [ hypothesis ];

  nativeBuildInputs = [ setuptools-scm ];

  propagatedBuildInputs = [ attrs py setuptools six pluggy ];

* In the `installCheck` phase, `${python.interpreter} setup.py test` is run.

By default tests are run because `doCheck = true`. Test dependencies, like

e.g. the test runner, should be added to `checkInputs`.

e.g. the test runner, should be added to `nativeCheckInputs`.

By default `meta.platforms` is set to the same value

as the interpreter unless overridden otherwise.

* `buildInputs ? []`: Build and/or run-time dependencies that need to be

  compiled for the host machine. Typically non-Python libraries which are being

  linked.

* `checkInputs ? []`: Dependencies needed for running the `checkPhase`. These

* `nativeCheckInputs ? []`: Dependencies needed for running the `checkPhase`. These

  are added to `nativeBuildInputs` when `doCheck = true`. Items listed in

  `tests_require` go here.

* `propagatedBuildInputs ? []`: Aside from propagating dependencies,

  buildPythonPackage {

    # ...

    # assumes the tests are located in tests

    checkInputs = [ pytest ];

    nativeCheckInputs = [ pytest ];

    checkPhase = ''

      runHook preCheck

* `setup_requires` corresponds to `nativeBuildInputs`

* `install_requires` corresponds to `propagatedBuildInputs`

* `tests_require` corresponds to `checkInputs`

* `tests_require` corresponds to `nativeCheckInputs`

## Contributing {#contributing}

##### `checkInputs` {#var-stdenv-checkInputs}

A list of dependencies used by the phase. This gets included in `nativeBuildInputs` when `doCheck` is set.

A list of host dependencies used by the phase, usually libraries linked into executables built during tests. This gets included in `buildInputs` when `doCheck` is set.

##### `nativeCheckInputs` {#var-stdenv-nativeCheckInputs}

A list of native dependencies used by the phase, notably tools needed on `$PATH`. This gets included in `nativeBuildInputs` when `doCheck` is set.

##### `preCheck` {#var-stdenv-preCheck}

##### `installCheckInputs` {#var-stdenv-installCheckInputs}

A list of dependencies used by the phase. This gets included in `nativeBuildInputs` when `doInstallCheck` is set.

A list of host dependencies used by the phase, usually libraries linked into executables built during tests. This gets included in `buildInputs` when `doInstallCheck` is set.

##### `nativeInstallCheckInputs` {#var-stdenv-nativeInstallCheckInputs}

A list of native dependencies used by the phase, notably tools needed on `$PATH`. This gets included in `nativeBuildInputs` when `doInstallCheck` is set.

##### `preInstallCheck` {#var-stdenv-preInstallCheck}

          instead.

        </para>

      </listitem>

      <listitem>

        <para>

          <literal>checkInputs</literal> have been renamed to

          <literal>nativeCheckInputs</literal>, because they behave the

          same as <literal>nativeBuildInputs</literal> when

          <literal>doCheck</literal> is set.

          <literal>checkInputs</literal> now denote a new type of

          dependencies, added to <literal>buildInputs</literal> when

          <literal>doCheck</literal> is set. As a rule of thumb,

          <literal>nativeCheckInputs</literal> are tools on

          <literal>$PATH</literal> used during the tests, and

          <literal>checkInputs</literal> are libraries which are linked

          to executables built as part of the tests. Similarly,

          <literal>installCheckInputs</literal> are renamed to

          <literal>nativeInstallCheckInputs</literal>, corresponding to

          <literal>nativeBuildInputs</literal>, and

          <literal>installCheckInputs</literal> are a new type of

          dependencies added to <literal>buildInputs</literal> when

          <literal>doInstallCheck</literal> is set. (Note that this

          change will not cause breakage to derivations with

          <literal>strictDeps</literal> unset, which are most packages

          except python, rust and go packages).

        </para>

      </listitem>

      <listitem>

        <para>

          <literal>borgbackup</literal> module now has an option for

- `carnix` and `cratesIO` has been removed due to being unmaintained, use alternatives such as [naersk](https://github.com/nix-community/naersk) and [crate2nix](https://github.com/kolloch/crate2nix) instead.

- `checkInputs` have been renamed to `nativeCheckInputs`, because they behave the same as `nativeBuildInputs` when `doCheck` is set. `checkInputs` now denote a new type of dependencies, added to `buildInputs` when `doCheck` is set. As a rule of thumb, `nativeCheckInputs` are tools on `$PATH` used during the tests, and `checkInputs` are libraries which are linked to executables built as part of the tests. Similarly, `installCheckInputs` are renamed to `nativeInstallCheckInputs`, corresponding to `nativeBuildInputs`, and `installCheckInputs` are a new type of dependencies added to `buildInputs` when `doInstallCheck` is set. (Note that this change will not cause breakage to derivations with `strictDeps` unset, which are most packages except python, rust and go packages).

- `borgbackup` module now has an option for inhibiting system sleep while backups are running, defaulting to off (not inhibiting sleep), available as [`services.borgbackup.jobs.<name>.inhibitsSleep`](#opt-services.borgbackup.jobs._name_.inhibitsSleep).

- `podman` now uses the `netavark` network stack. Users will need to delete all of their local containers, images, volumes, etc, by running `podman system reset --force` once before upgrading their systems.