The throwTestFailures tests in misc.nix produce confusing trace output
that looks like test failures even when tests pass.
This commit moves these tests to a new lib/tests/debug.sh script,
following the pattern from modules.sh, sources.sh, and filesystem.sh.
The confusing trace output does not appear in any logs anymore.
Example of the confusing log:
trace: FAIL "testDerivation":
Expected:
<derivation a>
Result:
<derivation b>
evaluation warning: Using `lib.generators.toPlist` without `escape = true` is deprecated
[ ]
Lists the valid choices in `attrTag` type's `description` field.
Given this description is used in error messages, this serves to make
for somewhat more descriptive errors in the event an option involving
this type turns out not to match.
Signed-off-by: cinereal <cinereal@riseup.net>
`lib.debug.runTests` provides a unit test evaluator for Nix, but its
results are returned in a raw and difficult-to-read form.
Currently, different callers output the results in various ways:
`builtins.throw (builtins.toJSON failures)` and `builtins.throw ("Tests
failed: " + lib.generators.toPretty { } failures)` are both used.
This change adds a new `lib.debug.throwTestFailures` function which
displays the results nicely before throwing an exception (or returns
`null` if no failures are given), unifying these disparate call-sites.
First, each failing test is pretty-printed in a `trace` message:
```
trace: FAIL testDerivation:
Expected: <derivation a>
Result: <derivation b>
```
Then, an exception is thrown containing the number of tests that failed
(and their names), followed by the raw JSON of the results (for parity
with previous usage, and because `lib.generators.toPretty` sometimes
omits information that `builins.toJSON` includes):
```
error:
… while evaluating the file '...':
… caused by explicit throw
at /nix/store/.../lib/debug.nix:528:7:
527| in
528| throw (
| ^
529| builtins.seq traceFailures (
error: 1 tests failed:
- testDerivation
[{"expected":"/nix/store/xh7kyqp69mxkwspmi81a94m9xx74r8dr-a","name":"testDerivation","result":"/nix/store/503l84nir4zw57d1shfhai25bxxn16c6-b"}]
```
This will allow the code for https://github.com/NixOS/nixpkgs/issues/447514
to make sure that the right team is requested for review,
even if it has been renamed in the meantime.
While the matching is currently based on the teams slug/name and not the
id, renames won't cause problems with `lib.teams`, because CI would
error if there's no match. Changing this can be future work.
The old cygwin support used -pc-windows-cygnus as the config. This is
supported by LLVM, but not by GNU. This will change it to -pc-cygwin,
which is more generally supported.
Because the kernel is now 'cygwin' rather than 'windows', isWindows will
return false. There are lots of different reasons isWindows is used in
nixpkgs, but in my experience they often have to do with posix
compatibility and don't apply to cygwin.
Co-authored-by: Brian McKenna <brian@brianmckenna.org>
This change introduces the suggesting of possible valid option names for
a given invalid option, based on the keys of said invalid option's
parent attrset. That is, `foo.bar.baz` will only be suggested keys from
`foo.bar`, while `(config).baz` will only be suggested keys from the
toplevel.
Allows marking an option as invisible, without excluding its sub-options.
In practice, this is similar to `visible = true; internal = true;`,
however it is more explicit and less reliant on implementation details.
renamed `mac` to `octets` in hextets combining step for better var
naming; rephrased error message to provide a hint of expected format;
replaced `Arguments` with `Inputs` in docstring; added more test cases
for invalid hex digits; added comments in hextets combining step;
A Cross Index, short for Cross Platform Pair Index, is the essential
shape of a splice, without the invoking the more mind bending concept
of adding variations of for these 6 pairings to an existing thing so
that it can be switched out for something else.
So the purpose of a Cross Index is to contain the result of `f`\
(which may be reified in code, or just an abstract concept):
- f "build" "build"
- f "build" "host"
- ...
Splicing on the other hand refers not just to these six variants, but
to the idea of tacking them onto one of the variants. (hostTarget,
I believe)
Cross Indexes are a necessity for making cross compilation work, but
splicing is more than necessary.
At the scale of Nixpkgs, actively maintaining a package is only possible
with integration into CI. To be able to be pinged for review requests,
the maintainer must have a GitHub handle, which:
- Leads to an invitation to the NixOS org, which comes with additional
privileges.
- Allows to request the maintainer for review as a member of this org.
- Automatically requests the maintainer for review in CI.
Currently, the GitHub handle is not strictly enforced. This leads to
some new maintainers accidentally forgetting to set these. We can avoid
these mistakes and enforce them via CI.
Tom Hubrecht