nix

nix copied to clipboard

It's extremely hard to debug such errors. It would help to print out the value of the list to see what's there that shouldn't be.

Oh, seems I was here already with a "thumbs up". Just hit this again. Isn't this really easy to fix? CC @edolstra.

Any updates?

Hit this issue again.

Newb here, I'm gettin this error when running nix-shell -E '(import ./default.nix).nodejs."13.6.0"', and the files are:

./default.nix

{pkgs ? import <nixpkgs> {}}: {
  nodejs = (import ./nodejs { inherit pkgs; })."13.6.0";
}

./nodejs/default.nix

{pkgs ? import <nixpkgs> {}}: {
  "13.6.0" = pkgs.callPackage ./nodejs.nix {
    inherit pkgs;
    version = "13.6.0";
    sha256 = "00f01315a867da16d1638f7a02966c608e344ac6c5b7d04d1fdae3138fa9d798";
  };
}

./nodejs/nodejs.nix

{ pkgs ? import <nixpkgs> {}, version, sha256 }:
  let
    inherit (pkgs) stdenv autoPatchelfHook platforms fetchurl;
    inherit (stdenv) mkDerivation lib;  
  in mkDerivation {
    inherit version;  
    name = "nodejs-${version}";  
    src = fetchurl {
      url = "https://nodejs.org/dist/v${version}/node-v${version}-linux-x64.tar.xz";
      inherit sha256;
    };
    nativeBuildInputs = with pkgs; [autoPatchelfHook];
    buildInputs = with pkgs; [glib];
    installPhase = ''
      mkdir -p $out
      cp -R ./ $out/
    '';  
    meta = {
      description = "Event-driven I/O framework for the V8 JavaScript engine";
      homepage = https://nodejs.org;
      license = lib.licenses.mit;
      platforms = lib.platforms.linux;
    };
  }

This issue is generally not the best place to get help with specific nixpkgs related errors. This issue tracker is for the evaluator for the Nix language. You could try on the discourse at https://discourse.nixos.org/ , or the #nixos channel on freenode at https://webchat.freenode.net/ , or perhaps on the nixpkgs issue tracker https://github.com/NixOS/nixpkgs/issues . Preferably one of the first two IMHO. That said, next time you have a problem it would help if you post a traceback, which you can usually get by passing --show-trace to the nix tools (but not always, we still have problems with inconsistent interfaces). Which is fitting for this issue, because we have no idea where to even look for the problem in your code. :P

cc @bburdette this one should be high priority for phase 3 of https://opencollective.com/nix-errors-enhancement

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/debugging-value-of-value-is-an-x-while-a-y-was-expected/11328/2

I think this one is going to be helped a lot with the new format error messages, where the line of code is displayed. The current error is something like this (using trusktr's example, above):

bburdette@BB-5520:~/code/nix-error-project/963$ nix-shell -E '(import ./default.nix).nodejs."13.6.0"'
error: value is a function while a set was expected, at (string):1:1

With the current version of nix, we get to see the context of the error:

bburdette@BB-5520:~/code/nix-error-project/963/test-case$ ~/op-code/nix/outputs/out/bin/nix-shell --version
nix-shell (Nix) 2.4
bburdette@BB-5520:~/code/nix-error-project/963/test-case$ ~/op-code/nix/outputs/out/bin/nix-shell -E '(import ./default.nix).nodejs."13.6.0"' 
error: value is a function while a set was expected

       at «string»:1:1:

            1| (import ./default.nix).nodejs."13.6.0"
             | ^

I think this is helpful because it shows the site of the error, which is in the cmdline argument passed to nix. The statement that the error was in a 'string' I think is confusing to noobs because maybe my code has a lot of strings? I don't think the message by itself is very clear that the error is in the cmdline argument. However, it pretty clear when accompanied by the line of code.

And it shows the exact expression that's supposed to be a set rather than a list/function/etc.

It might be helpful to show the value of that expression as well, but I'm not sure its strictly necessary.

similar (albeit contrived) example of the list error:

bburdette@BB-5520:~/code/nix-error-project/963/test-case$ ~/op-code/nix/outputs/out/bin/nix-shell -E '([1 2]).nodejs."13.6.0"'
error: value is a list while a set was expected

       at «string»:1:1:

            1| ([1 2]).nodejs."13.6.0"
             | ^

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/how-to-extract-signal-from-almost-useless-error-message/11733/13

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/node2nix-issue-at-import-node-env-nix-value-is-a-path-while-a-set-was-expected/12161/1

I marked this as stale due to inactivity. → More info

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/simple-runcommand-does-not-work/17373/1

The problem of nix spitting out errors without any trace, is not limited to the error mentioned in the issue title.

I encounter this quite regularly with different kinds of errors, like for example:

evaluation aborted with the following error message: 'cannot find attribute `''

which is an error triggered by an abort in lib/attrsets.nix

Whenever I track down these issues and write a simplified code snipped to reproduce it, the full trace is suddenly back. It seems like the trace only gets lost if the code is complex.

From my observation, it seems as the more complex the code is, the more likely it is that nix looses track of the trace, and starts spitting out error messages without any trace.

I'm not knowledgeable about nix' internals, but I'd guess that there must be a general architectural problem of how stack traces are recovered.

If it helps, I can provide a flake triggering an example of this issue.

@DavHau if you have an example that doesn't show traces when it should, I'd be interested in seeing it. The traces are built up during exception handling, and its not impossible that there might be a catch clause someplace that manages to throw away the traces.

@DavHau if you have an example that doesn't show traces when it should, I'd be interested in seeing it. The traces are built up during exception handling, and its not impossible that there might be a catch clause someplace that manages to throw away the traces.

Sorry, I noticed that I was accidentally using a pre-release version of nix 2.5. After upgrading to nix 2.7, the traces came back.

@bburdette

$ git clone https://github.com/yu-re-ka/robotnix
$ git checkout 946af3391337293e860b3803ca9098c4f0b36fa3
$ nix --version
nix (Nix) 2.10.3

$ nix-instantiate release-filtered.nix -A cached --show-trace
error: value is a set while a Boolean was expected

$ 

Not exactly the same error but also a type error missing a trace

I'd like such error messages to mention why a set (or whatever) was expected. For example

value is a function while a set was expected:
(import default.nix).asd
^

NOTE: a set was expected 
while trying to access the property `asd`
(import default.nix).asd
                     ^

I don't know how feasible this is without a better type system.

Closing since https://github.com/NixOS/nix/pull/6204 should have fixed most of these. Don't hesitate to open new issues if you encounter misleading or bad error messages on master.

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/2023-06-22-nix-team-meeting-minutes-65/29643/1