Closed mjhoy closed 7 years ago
I think Aeson's errors are generally good when the JSON is valid but the schema does not match (e.g. found a string where a number was expected), but not so good for invalid JSON. Looking at the response to a similar issue, though, it seems that the Aeson maintainers would be open to a PR improving this; that's probably the best approach to addressing this issue, I think.
this package might be worth considering as an alternative: https://github.com/FPBrno/aeson-parsec-picky
also, might be worth switch to eitherDecodeStrict
in either case, from decodeStrict
, and printing out the error message, which is more helpful in the event of valid json but an invalid schema, e.g.:
Error in $['dom-geolocation']: key "repo" not present
I don't think we should adopt a library which is more picky than what would be accepted by most other JSON parsers.
yeah, that's unfortunate.
i wonder if, ultimately, JSON is the right format to use here. psc-package makes a lot of sense to me, as i'm a little familiar with nixpkgs, but the process of manipulating json to, say, add missing packages or change forked package definitions, seems a little less than ideal and not really was json is designed for. but maybe i just need to turn on my emacs flycheck json mode :)
Fixed in 0.2.3, thanks.
Hi,
I'm using psc-package with a forked package-set. I am running into this error, which was pretty unhelpful. Is it possible to get better parsing errors? I played around with Aeson but the best I could get with
eitherDecodeStrict
was "Error in $: Failed reading: not a valid json value". I am not that familiar with Aeson so maybe there is a better solution?This also applies to psc-package.json, I believe.