mirror of
https://github.com/NixOS/nixpkgs.git
synced 2024-11-22 23:13:19 +00:00
doc: adapt to nativeCheckInputs
This commit is contained in:
Guillaume Girol
parent
b7042dc36a
commit
d26caea94b
@ -9,7 +9,7 @@ stdenv.mkDerivation {
|
||||
|
||||
# ...
|
||||
|
||||
checkInputs = [
|
||||
nativeCheckInputs = [
|
||||
postgresql
|
||||
postgresqlTestHook
|
||||
];
|
||||
|
||||
@ -436,7 +436,7 @@ arguments `buildInputs` and `propagatedBuildInputs` to specify dependencies. If
|
||||
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).
|
||||
@ -453,7 +453,7 @@ buildPythonPackage rec {
|
||||
hash = "sha256-FLLvdm1MllKrgTGC6Gb0k0deZeVYvtCCLji/B7uhong=";
|
||||
};
|
||||
|
||||
checkInputs = [ pytest ];
|
||||
nativeCheckInputs = [ pytest ];
|
||||
propagatedBuildInputs = [ numpy multipledispatch python-dateutil ];
|
||||
|
||||
meta = with lib; {
|
||||
@ -466,7 +466,7 @@ buildPythonPackage rec {
|
||||
```
|
||||
|
||||
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`.
|
||||
|
||||
@ -569,7 +569,7 @@ Pytest is the most common test runner for python repositories. A trivial
|
||||
test run would be:
|
||||
|
||||
```
|
||||
checkInputs = [ pytest ];
|
||||
nativeCheckInputs = [ pytest ];
|
||||
checkPhase = ''
|
||||
runHook preCheck
|
||||
|
||||
@ -585,7 +585,7 @@ sandbox, and will generally need many tests to be disabled.
|
||||
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
|
||||
@ -618,7 +618,7 @@ when a package may need many items disabled to run the test suite.
|
||||
Using the example above, the analogous `pytestCheckHook` usage would be:
|
||||
|
||||
```
|
||||
checkInputs = [ pytestCheckHook ];
|
||||
nativeCheckInputs = [ pytestCheckHook ];
|
||||
|
||||
# requires additional data
|
||||
pytestFlagsArray = [ "tests/" "--ignore=tests/integration" ];
|
||||
@ -749,7 +749,7 @@ with the exception of `other` (see `format` in
|
||||
`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" ];
|
||||
```
|
||||
@ -1006,7 +1006,7 @@ buildPythonPackage rec {
|
||||
rm testing/test_argcomplete.py
|
||||
'';
|
||||
|
||||
checkInputs = [ hypothesis ];
|
||||
nativeCheckInputs = [ hypothesis ];
|
||||
nativeBuildInputs = [ setuptools-scm ];
|
||||
propagatedBuildInputs = [ attrs py setuptools six pluggy ];
|
||||
|
||||
@ -1028,7 +1028,7 @@ The `buildPythonPackage` mainly does four things:
|
||||
* 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.
|
||||
@ -1082,7 +1082,7 @@ because their behaviour is different:
|
||||
* `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,
|
||||
@ -1416,7 +1416,7 @@ example of such a situation is when `py.test` is used.
|
||||
buildPythonPackage {
|
||||
# ...
|
||||
# assumes the tests are located in tests
|
||||
checkInputs = [ pytest ];
|
||||
nativeCheckInputs = [ pytest ];
|
||||
checkPhase = ''
|
||||
runHook preCheck
|
||||
|
||||
@ -1768,7 +1768,7 @@ In a `setup.py` or `setup.cfg` it is common to declare dependencies:
|
||||
|
||||
* `setup_requires` corresponds to `nativeBuildInputs`
|
||||
* `install_requires` corresponds to `propagatedBuildInputs`
|
||||
* `tests_require` corresponds to `checkInputs`
|
||||
* `tests_require` corresponds to `nativeCheckInputs`
|
||||
|
||||
## Contributing {#contributing}
|
||||
|
||||
|
||||
@ -654,7 +654,11 @@ A list of strings passed as additional flags to `make`. Like `makeFlags` and `ma
|
||||
|
||||
##### `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}
|
||||
|
||||
@ -821,7 +825,11 @@ A list of strings passed as additional flags to `make`. Like `makeFlags` and `ma
|
||||
|
||||
##### `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}
|
||||
|
||||
|
||||
@ -146,6 +146,30 @@
|
||||
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
|
||||
|
||||
@ -48,6 +48,8 @@ In addition to numerous new and upgraded packages, this release has the followin
|
||||
|
||||
- `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.
|
||||
|
||||
Loading…
Reference in New Issue
Block a user