Infinite recursion encountered after updating nixpkgs #281
Comments
|
Can you please have a look at #280 and check whether it fixes your issue? |
|
Thanks for the quick reply. I merged aszlig@fb21be5 and now I'm getting the infinite recursion in another place than before: The offending line is nothing special and worked before: config = mkIf cfg.enable { ... } |
|
@basvandijk: Are you using references to |
|
Does that module do something like: ? That no longer works, you have to say |
|
Yes I had that line, after removing it the infinite recursion is gone. Thanks. However I now get the following error: |
|
@nbp Any idea? |
|
@basvandijk: Can you re-run show-physical with |
|
|
|
Ah, never mind, it actually shows the expression as XML but coming from NixOS-instantiate, and doesn't show the generated input expression though. Setting |
|
Setting xml = subprocess.check_output(
["nix-instantiate"]
+ self.extra_nix_eval_flags
+ self._eval_flags(self.nix_exprs) +
["--eval-only", "--xml", "--strict",
"--arg", "checkConfigurationOptions", "false",
"-A", "info"], stderr=self.logger.log_file)The actual |
|
Regarding the error: which is thrown from deepOverrider = newArgs: name: x: if builtins.isAttrs x then (
if x ? deepOverride then (x.deepOverride newArgs) else
if x ? override then (x.override newArgs) else
x) else x;The strange thing is that it's preceded by a |
|
So maybe this is caused by: NixOS/nixpkgs@8921a8f. @shlevy the commit message speaks about a too old Could that be the problem? |
|
1.8 should be new enough. All those trace messages suggest something else is going on, such as a deep evaluation of the |
|
Indeed, I tried it with Nix-1.9pre4088_1711679 and that gives the same error. So I guess the best place to start debugging this possible |
|
@basvandijk , Do you have a definition of |
|
oh, I guess the obsolete messages are coming from https://github.com/NixOS/nixops/blob/master/nix/eval-machine-info.nix#L58 |
|
Indeed. The warnings are now fixed by a patch from @edolstra. The error remains though: |
|
I'm experiencing the same problem trying to deploy to AWS. |
|
Indeed it only seems to occur for The following is a minimal test case that fails: let aws = {
region = "<YOUR EC2 REGION>";
accessKeyId = "<YOUR AWS ACCESS KEY ID>";
};
in {
network.description = "Debug network";
debug = { config, pkgs, resources, ... }: {
deployment = {
targetEnv = "ec2";
ec2 = {
inherit (aws) region accessKeyId;
keyPair = resources.ec2KeyPairs.nixops-keypair;
instanceType = "m3.large";
ebsBoot = true;
ebsInitialRootDiskSize = 32; #GB
};
};
};
resources = {
ec2KeyPairs.nixops-keypair = {
inherit (aws) region accessKeyId;
name = "nixops-keypair";
};
};
} |
|
|
|
Yes, I posted a separate issue about that here #282. |
|
When I set @shlevy any idea why that line is causing the trouble? |
|
@basvandijk No idea, sorry. No code calling |
|
Ok. It definitely seems to come from the evalResources function. |
|
The problem is because it tries to evaluate whole nixpkgs |
|
Don't have time to look into this right now, but IIRC there was some code to filter out specific values from the module evaluation before serializing to XML. @edolstra Is that maybe the culprit here, some new value that hasn't been filtered out? |
|
Meh, i can't deploy on ec2 now, what's advised workaround? |
|
So is this nix or nixops related issue? |
|
Ok, workaround for me was reverting new module system NixOS/nixpkgs#2540 |
|
I'm stuck on this, too. Reverted to the old module system for now. Unfortunately no minimal test because our deployment is so big and hard to boil down to something small. |
|
I'm not sure if this is relevant, and I don't understand why it fixes things, but I've had some luck on my EC2 instances by emulating this commit in my configuration.nix. |
|
Me too. I'm trying to GCE deployment with the latest and greatest: |
|
Seems to be related to #284 |
|
@oconnorr I was able to reproduce your issue and fix it by pushing NixOS/nixpkgs@ad0bd73 . |
|
Strange. Rob, I merged in your change into my repository, but I still have the same error. |
|
Well, the infinite recursion can be triggered in many different ways. For instance, if you have a module that uses |
|
My trivial-gce.nix is very trivial: |
|
There is a "with pkgs.lib" in /nix/store/kslm406j6b8gl9k43lvdsxwdz5i7xbpc-nixops-1.3pre1362_2a616f8/share/nix/nixops/libvirtd.nix Do I have to rebuild nixops? What is the best way of doing that? Running isn't sufficent. |
|
@oconnorr I have the following setup for running nixops-HEAD: I have the following #!/usr/bin/env bash
cmd="nixops"
for var in "$@"
do
cmd="${cmd} \"$var\""
done
nix-shell nixops-HEAD-env.nix -I .. --command "$cmd"
# This file adds nixops-HEAD to the environment so we can
# benefit from the latest bug-fixes.
#
# It depends on the source of nixops to be in the ./nixops directory.
#
# We currently have nixops checked out in ./nixops as a git submodule.
{ pkgs ? import <nixpkgs> {} }:
let nixopsUnstable = pkgs.callPackage
<nixpkgs/pkgs/tools/package-management/nixops/unstable.nix> {};
nixopsHEAD = pkgs.stdenv.lib.overrideDerivation nixopsUnstable (oldAttrs: {
name = "nixops-HEAD";
src = ./nixops;
patches = [];
});
in
pkgs.myEnvFun {
name = "nixops-HEAD";
buildInputs = [
nixopsHEAD
];
} |
|
Replacing the version worked for me:
|
|
Things seem to be working for me now. |
|
It's also working for me these days so I'm closing the issue. Thanks for your help everybody! |
I just updated my
nixpkgsto NixOS/nixpkgs@1035b7b and now mostnixopscommands detect an infinite recursion which seems to start at the nixopsec2.nixfile at line 405. For example:Note I'm also using the latest
nixops(372333a).@rbvermaa Could it have something todo with: NixOS/nixpkgs@824fccd ?
The text was updated successfully, but these errors were encountered: