You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
When importing JSON or TOML files in Nix code, it's not obvious where the data is coming from whenever an error is happening.
$ nix-instantiate --eval demo.nix
error: --- JSONParseError ---------------------------------------------------- nix-instantiate
[json.exception.parse_error.101] parse error at line 5, column 13: syntax error while parsing array - unexpected string literal; expected ']'
It's great that the error shows in which line of the JSON the error is happening, but the user doesn't know from which file it's happening. To find that out, they have to dig into the Nix code.
A general principle in error reporting is to measure how much effort the user has to go through to find a resolution to the problem. How many hoops they have to jump through. Right now it is not completely straight-forward.
As we see in the example, the readFile path has long been forgotten when fromJSON is being called.
I can see multiple potential solutions:
Add more builtins. Implement importJSON and importTOML (and importYAML?). That makes it trivial to report the path since the function has access to both data. The downside is that it adds more builtins.
Extend the string context to contain the source of the data. And change fromJSON to take advantage of the extra data during error reporting. The advantage is that this change could be done transparently without changing any of the APIs. Users that upgrade Nix will automatically get the improved error messages.
Re-implement importJSON with tryEval to extend the error message. I haven't really thought of the implications of this one as it seems like the clunkiest approach (it sort of breaks the lazy evaluation).
Solution 2 is my preferred one as it allows to disconnect the read from the eval.
The text was updated successfully, but these errors were encountered:
$ /nix/store/hbwdvww1nqdav95iggp4zpgnpcwk037b-nix-2.6.0pre19700101_59a5f35/bin/nix-instantiate foo.nix --show-trace
error: [json.exception.parse_error.101] parse error at line 5, column 13: syntax error while parsing array - unexpected string literal; expected ']'
… while decoding a JSON string
at /home/domen/dev/nixpkgs/foo.nix:2:22:
1| let
2| importJSON = file: builtins.fromJSON (builtins.readFile file);
| ^
3| in
… while evaluating 'importJSON'
at /home/domen/dev/nixpkgs/foo.nix:2:16:
1| let
2| importJSON = file: builtins.fromJSON (builtins.readFile file);
| ^
3| in
… from call site
at /home/domen/dev/nixpkgs/foo.nix:4:3:
3| in
4| importJSON ./demo.json
| ^
Is your feature request related to a problem? Please describe.
When importing JSON or TOML files in Nix code, it's not obvious where the data is coming from whenever an error is happening.
It's great that the error shows in which line of the JSON the error is happening, but the user doesn't know from which file it's happening. To find that out, they have to dig into the Nix code.
A general principle in error reporting is to measure how much effort the user has to go through to find a resolution to the problem. How many hoops they have to jump through. Right now it is not completely straight-forward.
./demo.nix
./demo.json
Describe the solution you'd like
As we see in the example, the
readFile
path has long been forgotten whenfromJSON
is being called.I can see multiple potential solutions:
Add more builtins. Implement
importJSON
andimportTOML
(andimportYAML
?). That makes it trivial to report the path since the function has access to both data. The downside is that it adds more builtins.Extend the string context to contain the source of the data. And change
fromJSON
to take advantage of the extra data during error reporting. The advantage is that this change could be done transparently without changing any of the APIs. Users that upgrade Nix will automatically get the improved error messages.Re-implement
importJSON
withtryEval
to extend the error message. I haven't really thought of the implications of this one as it seems like the clunkiest approach (it sort of breaks the lazy evaluation).Solution 2 is my preferred one as it allows to disconnect the read from the eval.
The text was updated successfully, but these errors were encountered: