Infinite Recursion when following Overlay installation instructions #980
Labels
No labels
Affects/CppNix
Affects/Nightly
Affects/Only nightly
Affects/Stable
Area/build-packaging
Area/cli
Area/evaluator
Area/fetching
Area/flakes
Area/language
Area/lix ci
Area/nix-eval-jobs
Area/profiles
Area/protocol
Area/releng
Area/remote-builds
Area/repl
Area/repl/debugger
Area/store
bug
Context
contributors
Context
drive-by
Context
maintainers
Context
RFD
crash 💥
Cross Compilation
devx
docs
Downstream Dependents
E/easy
E/hard
E/help wanted
E/reproducible
E/requires rearchitecture
imported
Language/Bash
Language/C++
Language/NixLang
Language/Python
Language/Rust
Needs Langver
OS/Linux
OS/macOS
performance
regression
release-blocker
stability
Status
blocked
Status
invalid
Status
postponed
Status
wontfix
testing
testing/flakey
Topic/Large Scale Installations
ux
No milestone
No project
No assignees
5 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: lix-project/lix#980
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Describe the bug
When following the updated install instruction for the "advanced config", I added the following to my nix config:
When attempting to build this configuration, I was presented with:
elsewhere in my config I have direnv enabled:
Removing this configuration resolved the issue.
I was also able to resolve the issue by removing the lix overlay for nix-direnv and adjusting my direnv config like so:
However I am not sure if this is ideal.
Steps To Reproduce
Expected behavior
I would expect the overlay to be compatible with my existing configuration and to function without modification.
nix --version
outputnix (Lix, like Nix) 2.91.3
Additional context
Add any other context about the problem here.
Does the issue persist if you remove only the
package = pkgs.nix-direnv;
line in your configuration?@qyriad wrote in #980 (comment):
Yes, It occurs even if the only direnv config is enable = true. I tried it with that line removed. Then I tried it with the entire nix-direnv section removed and it still had the issue.
Oh, it is a documentation error — it should be
inherit (prev.lixPackageSets.stable) …
.I'll fix the docs, but that should fix your issue @eve-vxs
Hello! I can reproduce this issue. It happens in both my own system and a very minimal flake configuration. Changing it to
prev.lixPackageSets.stable
does not solve the issue.Very minimal reproducer flake, built with
nixos-rebuild build --flake .#example
Interestingly, in the reproducer, commenting out all but one of the items in
environment.SystemPackages
fails forcolmena
,nix-direnv
,nix-fast-build
, andnixpkgs-review
, but the build succeeds if onlynix-eval-jobs
is included. I'm not familiar enough with the internals to understand why.I'm having the same issue, even after correcting my overlay as above. Everything builds fine if I overlay all the packages except
nix-direnv
(sonixpkgs-review
,nix-eval-jobs
,nix-fast-build
andcolmena
are overlaid with those fromprev.lixPackageSets.stable
), but as soon as I addnix-direnv
I get the same infinite recursion error.For reference, my current direnv config is as follows:
Perhaps, we are actually debugging another problem pertaining to nix-direnv only?
Possibly? I think the recursion is coming from
nix-direnv
already being overridden here, so when the lix overlay also overrides the same package (throughpkgs.lixPackageSets.stable.nix-direnv
) it gets caught up trying to apply the overrides on top of each other?I'm not sure how this would be solved on either end, is it a case of giving the overrides a priority and applying them in sequence somehow? I haven't been able to find any similar instances online.
Full trace when trying to overlay `nix-direnv`
The thing that's extra confusing is that I get the error even when providing a new value for package (which I would think would avoid the recursion by giving it a new value?
Also if Lix still lazy evaluates, when I removed the nix-direnv bit of config from programs.direnv, the package property shouldn't even evaluate because the property shouldn't even be read? or am I misunderstanding?
Also tried building with the latest version of the instructions from the page (which states to use final not prev as in this thread) and had the same issue.
Is the solution here maybe just to override programs.direnv as well?
@joegilkes wrote in #980 (comment):
That's correct.
The solution here is to remove
nix-direnv
from your overrides. As long as you donix.package = pkgs.lixPackageSets.lix.stable;
,nix-direnv
will follow through as long as they keep this API.It's quite uncommon/unexpected for a package to perform such things and this renders overlaying more complicated as you can see.
I will update the instructions to take into account this aspect, thank you all.