Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

flakes: flake inputs incorrectly following from the root of the current flake #5697

Closed
nrdxp opened this issue Nov 30, 2021 · 7 comments · Fixed by #5713 or #6036
Closed

flakes: flake inputs incorrectly following from the root of the current flake #5697

nrdxp opened this issue Nov 30, 2021 · 7 comments · Fixed by #5713 or #6036
Labels
bug

Comments

@nrdxp
Copy link

nrdxp commented Nov 30, 2021 •
edited
Loading

Describe the bug

I noticed recent versions of Nix in the last month or so had strange follows behavior that caused some errors I wasn't seeing before. I boiled it down to this: flake inputs now seem to want to track their follows from the root of the consuming flake, rather than from their own root as it was before. This means that if flake B has inputs C and D with C.follows = "D/C", and flake A pulls B as an input, you'll now see an error when trying to generate A's lockfile like so:

error: input 'B/C' follows a non-existent input 'D/C'

Whereas before, this error did not occur and C would correctly come from B's lockfile, that is: "B/D/C". Now it seems Nix no longer knows about "B/D/C" and thinks "D" doesn't exist at all.

Steps To Reproduce

Just so happens this is occurring in a public work repo so you can refernce it to reproduce:

  1. get or build nix on or after the offending commit: 07bffe7 (discovered with git bisect)
  2. run nix flake info github:input-output-hk/bitte/b6f9b26935425a2efadb9b35201c99916ced3a33
  3. You should then see the following error:
error: input 'bitte-cli/nixpkgs' follows a non-existent input 'fenix/nixpkgs'
  1. If you'd like to see the old behavior, simply get a build of Nix before the aforementioned commit and notice how there is no error

Expected behavior

Since follows are declared in flake B, it would make sense they would try to follow starting from its root, and not the root of the consuming flake.
@nrdxp nrdxp added the bug label Nov 30, 2021
@nrdxp
Copy link
Author

nrdxp commented Nov 30, 2021

@balsoft as the original author of the offending commit, I wonder if you may have an idea of what's going on?

@balsoft
Copy link
Member

balsoft commented Dec 1, 2021

Here we go again...

I'll look into it on the weekend

balsoft added a commit to tweag/nix that referenced this issue Dec 2, 2021
@balsoft
Flakes: computeLocks: pass correct LockParent when reusing oldLock
7f11dcb 
Previously, when we were attemptint to reuse the old lockfile
information in the computeLocks function, we have passed the parent of
the current input to the next computeLocks call. This was incorrect,
since the follows are resolved relative to the parent. This caused
issues when we tried to reuse oldLock but couldn't for some
reason (read: mustRefetch is true), in that case the follows were
resolved incorrectly.

Fix this by passing the correct parent, and adding some tests to
prevent this particular regression from happening again.

Closes NixOS#5697
@balsoft balsoft mentioned this issue Dec 2, 2021
Merged
balsoft added a commit to tweag/nix that referenced this issue Dec 2, 2021
@balsoft
Flakes: computeLocks: pass correct LockParent when reusing oldLock
8cbf862 
Previously, when we were attempting to reuse the old lockfile
information in the computeLocks function, we have passed the parent of
the current input to the next computeLocks call. This was incorrect,
since the follows are resolved relative to the parent. This caused
issues when we tried to reuse oldLock but couldn't for some
reason (read: mustRefetch is true), in that case the follows were
resolved incorrectly.

Fix this by passing the correct parent, and adding some tests to
prevent this particular regression from happening again.

Closes NixOS#5697
@smunix
Copy link

smunix commented Dec 2, 2021

Thanks @balsoft ! I can confirm, the fix works here

@sheyll
Copy link

sheyll commented Jan 28, 2022 •
edited
Loading

Might it be possible that this bug came back?

@balsoft should I open a new issue for this?

I'm trying the current 2.6 release and get the same behaviour:

[sven@fedora lbm]$ nix --version
nix (Nix) 2.6.0
[sven@fedora lbm]$ nix flake info github:input-output-hk/bitte/b6f9b26935425a2efadb9b35201c99916ced3a33
warning: 'nix flake info' is a deprecated alias for 'nix flake metadata'
error: input 'cli/nixpkgs' follows a non-existent input 'fenix/nixpkgs'
(use '--show-trace' to show detailed location information)

@balsoft
Copy link
Member

balsoft commented Jan 28, 2022

I've left a bisect running. Let's see what broke it.

balsoft added a commit to tweag/nix that referenced this issue Feb 2, 2022
@balsoft
Flake follows: resolve all follows to absolute
169ea0b 
It's not possible in general to know in computeLocks, relative to
which path the follows was intended to be. So, we always resolve
follows to their absolute states when we encounter them (which can
either be in parseFlakeInput or computeLocks' fake input population).

Fixes NixOS#6013
Fixes NixOS#5609
Fixes NixOS#5697 (again)
@balsoft balsoft mentioned this issue Feb 2, 2022
Merged
@balsoft
Copy link
Member

balsoft commented Feb 2, 2022

Resolved again by #6036

@carnotweat
Copy link

I still see the hyprland-wm and hyprland-plugins.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug
Projects
None yet
Milestone
No milestone
5 participants
@sheyll @smunix @carnotweat @balsoft @nrdxp