Transitive inputs "not in registry" #5790
Comments
|
I can indeed reproduce this. More self-contained repro: #!/usr/bin/env bash
set -euo pipefail
set -x
rm -rf A B C D
mkdir -p A B C D
cat <<EOF > A/flake.nix
{ outputs = _: {}; }
EOF
cat <<EOF > B/flake.nix
{
inputs.A.url = "path:$PWD/A";
outputs = _: {};
}
EOF
cat <<EOF > C/flake.nix
{
inputs.B.url = "path:$PWD/B";
outputs = _: {};
}
EOF
cat <<EOF > D/flake.nix
{
inputs.C.url = "path:$PWD/C";
inputs.A.url = "path:$PWD/A";
inputs.C.inputs.B.inputs.A.follows = "A";
outputs = _: {};
}
EOF
nix flake update ./D |
|
This issue has been mentioned on NixOS Discourse. There might be relevant details there: |
|
may have been fixed in #6036 |
|
Nope. Running thuf's script still fails: |
|
The desired change to the resulting lockfile for the relevant "follows" line, should cause this: I've tried a few combination such as bringing B to the top and they trying to override it: but then the relevant line to follow A has no effect. What does work is to bring everything to the top level: This can work in some cases if all you need is top level access to those inputs, but it does not allow you to change them, which is where people run into this problem. |
Ma27
added a commit
to Ma27/nix
that referenced
this issue
Jun 13, 2022
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].
[1] 2664a21
[2] NixOS#5790
Ma27
added a commit
to Ma27/nix
that referenced
this issue
Jun 13, 2022
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] 2664a21
[2] NixOS#5790
Ma27
added a commit
to Ma27/nix
that referenced
this issue
Jul 12, 2022
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] 2664a21
[2] NixOS#5790
|
Have you found any work-around for this? |
|
@azazel75, yes, I now use https://github.com/deemp/flakes/blob/main/flake.nix |
8 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
I want to use
followson the input of an input.Though I get an error, that this is not in the registry.
Steps To Reproduce
nixpkgsinput to aflake.nix.flake.nixat appropriate location:flake.lockand observe error:Expected behavior
The
nixpkgsinput of thenaerskinput ofrnix-lspis properly overwritten and follows "my"nixpkgs.nix-env --versionoutputAdditional context
I tried this as a way to workaround #5609.
The same problem happens on 2.4 and 2.5:
The text was updated successfully, but these errors were encountered: