flakes: throw an error if follows-declaration for an input is invalid#6663
Merged
thufschmitt merged 3 commits intoNixOS:masterfrom Jul 12, 2022
Merged
flakes: throw an error if follows-declaration for an input is invalid#6663thufschmitt merged 3 commits intoNixOS:masterfrom
follows-declaration for an input is invalid#6663thufschmitt merged 3 commits intoNixOS:masterfrom
Conversation
Member
Author
|
ping @edolstra @thufschmitt would you mind taking a look? :) |
thufschmitt
suggested changes
Jul 12, 2022
Member
thufschmitt
left a comment
There was a problem hiding this comment.
Thanks :)
A few comments, but looks good overall
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
2003172 to
1f77106
Compare
thufschmitt
approved these changes
Jul 12, 2022
lf-
pushed a commit
to lix-project/lix
that referenced
this pull request
May 5, 2024
… works recursively When I added the warning that an input X has an override for a non-existent input, the recursive flake input override fix wasn't implemented yet[1]. This patch tests that both work together. [1] NixOS/nix#6663 Change-Id: I90dc032029b7160ab4a97d28c480c59d3a6f0150
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I recently got fairly confused why the following expression didn't have
any effect
until I found out that the input was called
nixpkgs-22_05(please notethe 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 fromoverrides 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
followswas apparently forgotten[1].Since the key of the
std::mapthat holds theoverridesis a vectorand 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
nbeingthe total amount of overrides (which shouldn't be that large though).
Please note that this doesn't work with nested expressions, i.e.
which is a known problem[2].
For the expression demonstrated above, an error like this will be
thrown:
[1] 2664a21
[2] #5790
cc @edolstra @thufschmitt @Ericson2314