E.g.
… while evaluating the attribute 'buildCommand' of the derivation 'vm-test-run-github-flakes'
at «github:NixOS/nixpkgs/2fa57ed190fd6c7c746319444f34b5917666e5c1»/pkgs/stdenv/generic/make-derivation.nix:278:7:
I recently got fairly confused why the following expression didn't have
any effect
{
description = "Foobar";
inputs.sops-nix = {
url = github:mic92/sops-nix;
inputs.nixpkgs_22_05.follows = "nixpkgs";
};
}
until I found out that the input was called `nixpkgs-22_05` (please note
the dash vs. underscore).
IMHO it's not a good idea to not throw an error in that case and
probably leave end-users rather confused, so I implemented a small check
for that which basically checks whether `follows`-declaration from
overrides actually have corresponding inputs in the transitive flake.
In fact this was done by accident already in our own test-suite where
the removal of a `follows` was apparently forgotten[1].
Since the key of the `std::map` that holds the `overrides` is a vector
and we have to find the last element of each vector (i.e. the override)
this has to be done with a for loop in O(n) complexity with `n` being
the total amount of overrides (which shouldn't be that large though).
Please note that this doesn't work with nested expressions, i.e.
inputs.fenix.inputs.nixpkgs.follows = "...";
which is a known problem[2].
For the expression demonstrated above, an error like this will be
thrown:
error: sops-nix has a `follows'-declaration for a non-existant input nixpkgs_22_05!
[1] 2664a216e5
[2] https://github.com/NixOS/nix/issues/5790
Relative 'path:' inputs are now handled correctly in
call-flake.nix. This does require the lock file to record what the
'parent' is relative to which a node's source should be fetched.
Prevents errors when running with UBSan:
/nix/store/j5vhrywqmz1ixwhsmmjjxa85fpwryzh0-gcc-11.3.0/include/c++/11.3.0/bits/stl_pair.h:353:4: runtime error: load of value 229, which is not a valid value for type 'AttrType'
Overrides for inputs with flake=false were non-sticky, since they
changed the `original` in `flake.lock`. This fixes it, by using the same
locked original for both flake and non-flake inputs.
This replaces the 'patches' argument to builtins.fetchTree with
something more generic. So instead of 'builtins.fetchTree { patches =
... }' you can do 'builtins.patch { src = builtins.fetchTree { ... };
patchFiles = ... }'.
Relative 'path:' flake inputs now use the containing flake's
InputAccessor. This has the following implications:
* They're no longer locked in the lock file.
* They don't cause an additional copy to the store.
* They can reference the containing directory (i.e. a subflake can
have an input '../foo', so long as it doesn't go outside the
top-level containing flake).
Note: this is not a complete fix for subflake handling, since the lock
file currently makes it ambiguous what the containing flake is. We'll
probably need to add another field to the lock file for that.
Fixes#6352.
