Consider a derivation a value to be serialized.
nix-repl> lib.generators.toGitINI { hello = { drv = pkgs.hello; }; }
error: evaluation aborted with the following error message: 'generators.mkValueStringDefault: attrsets not supported: <derivation /nix/store/533q15q67sl6dl0272dyi7m7w5pwkkjh-hello-2.10.drv>'
Fixes #137390
The current implementation of the concatStringsSep fallback references
concatStrings whcih is just a partial application of concatStringsSep,
forming a circular dependency. Although this will almost never be
encountered as (assuming the user does not explicitly trigger it):
1. the or operator will short circuit both in lazy and strict
evaluation
2. this can only occur in Nix versions prior to 1.10
which is not compatible with various nix operations as of 2.3.15
However it is still important if scopedImport is used or the builtins
have been overwritten. lib.foldl' is used instead of builtins.foldl'
as the foldl' primops was introduced in the same release as concatStringsSep.
- Remove inheritance of `lists.fold` as it isn't used anywhere.
- Inherit `foldl'` for consistency as only `cartesianProductOfSets` explicitly
reference lib.
- Inline `foldr` to generate nested attrs instead of using `listToAttrs` and `tail`.
This allows checking e.g. stdenv.hostPlatform.isGnu, just like isMusl
or isUClibc. It was already possible to check for glibc with
stdenv.hostPlatform.libc == "glibc", but when that doesn't line up
with how every other platform check works, this is apparently
sufficiently non-obvious that we've ended up with stuff like adding
glibc.static if !isMusl, which is obviously wrong.
This regressed in 9c213398b3
The recursiveUpdate gave the platform both gcc.cpu and gcc.arch attrs
instead of only gcc.cpu. This is invalid; gcc configuration fails with:
```
Switch "--with-arch" may not be used with switch "--with-cpu"
```
So we revert to using `//` to retain only gcc.cpu
(which is more specific than the processor arch).
Trying to create a simple flake with input:
```
{
inputs.nixpkgs-lib.url = "github:NixOS/nixpkgs?dir=lib";
outputs = {nixpkgs-lib, ...}: { };
}
```
Fails when trying to evaluate the nixpkgs-lib flake with an error like:
```
error: getting status of '/nix/store/xxxx-source/lib/lib': No such file or directory
(use '--show-trace' to show detailed location information)
```
Allows for distinction of licenses that are unfree overall but do grant the
right to redistribute. Defaults to the freeness of the license.
Note: Many unfree but are redistributable licenses aren't marked as such.
I expect that to be fixed in a distributed manner over time.
Closes https://github.com/NixOS/nixpkgs/pull/97789
Previously, if a derivation without a `drvPath` was handled, an error
would be thrown:
nix-repl> lib.generators.toPretty {} { type = "derivation"; }
error: attribute 'drvPath' missing, at /home/infinisil/src/nixpkgs/lib/generators.nix:251:24
With this commit it doesn't anymore:
nix-repl> lib.generators.toPretty {} { type = "derivation"; }
"<derivation ???>"
This matches what `nix repl` outputs:
nix-repl> { type = "derivation"; }
«derivation ???»
For an option definition that uses `lib.options.mergeEqualOption`
underneath, like `types.anything`, an error is thrown when multiple
functions are assigned, indicating that functions can't be compared for
equivalence:
error: The option `test' has conflicting definition values:
- In `xxx': <function>
- In `xxx': <function>
(use '--show-trace' to show detailed location information)
However, the error message didn't use the correct files. While above
error indicates that both definitions are in the xxx file, that's in
fact not true. Above error was generated with
options.test = lib.mkOption {
type = lib.types.anything;
};
imports = [
{
_file = "yyy";
test = y: y;
}
{
_file = "xxx";
test = x: x;
}
];
With this change, the error uses the correct file locations:
error: The option `test' has conflicting definition values:
- In `xxx': <function>
- In `yyy': <function>
(use '--show-trace' to show detailed location information)
so the underlaying use case of the preceding commit is so
generic, that we gain a lot in reasoning to give it an
appropriate name.
As the comment states:
image media needs to override host config short of mkForce
m68k was recently added for Linux and none, but NetBSD also supports
m68k. Nothing will build yet, but I want to make sure we at least
encode the existence of NetBSD support for every applicable
architecture we support for other operating systems.
In Autoconf, some old NetBSD targets like "i686-unknown-netbsd" are
interpreted as a.out, not elf, and virtually nothing supports it. We
need to specify e.g. "i686-unknown-netbsdelf" to get the right
behaviour.
