Support better error hints when importing data from Parser sources #79

New Issue

2025-12-30T01:20:31+01:00

adam commented

2025-12-30 01:20:31 +01:00

Originally created by @Senjai on GitHub (Feb 19, 2024).

Philliam and I were discussing JSON error reporting in Discord.

Currently, there is no pkl import type command I am aware of that allows us to import JSON/YAML/etc into PKL, so I am making the assumption the only way to bring in external data is through the Parser subclasses.

For this example we'll use JSON.

Consider the following

import "pkl:json"

hidden parser: json.Parser = new {}

class JsonType {
  hello: String
  test: Int
}

data = parser.parse(read("file:intro.json"))
// intro.json has a type mismatch on test, it's a string instead of an int
verified: JsonType = data.toTyped(JsonType)

intro.json

{ "hello": "world", "test": "oops" }

The error I see here is:

Expected value of type `Int`, but got type `String`.
Value: "oops"

7 | test: Int
          ^^^
at thing#JsonType.test (file:///thing.pkl, line 7)

While this offers a value hint that I can then grep intro.json for to find, if you have a sufficiently large JSON file this becomes challenging to rely on for debugging purposes.

Some other configuration languages, such as cue have errors that can look like this:

verticals.4.categories.767.attributes.0.name: conflicting values "Absinthe style" and "Age group":             
    ./attributes_data.cue:248:8                        
    ./categories_data.cue:119611:10                                                                            
    ./schema.cue:39:14                                 
    ./schema.cue:42:16

While this error message isn't fantastic either, it does identify that the problem is with the 5th vertical, and 768th attribute, which gives much higher signal on how to go about dealing with the error.

I'd love to see either the parser be smarter about reporting on errors in this fashion, even if it dynamically just references the path of the data that's problematic, or if there's a way we can pkl import non pkl files, as an analogue to pkl eval -f format so that we can get native PKL error reporting on these issues.

Originally created by @Senjai on GitHub (Feb 19, 2024). Philliam and I were discussing JSON error reporting in Discord. Currently, there is no `pkl import` type command I am aware of that allows us to import JSON/YAML/etc into PKL, so I am making the assumption the only way to bring in external data is through the Parser subclasses. For this example we'll use JSON. Consider the following ```pkl import "pkl:json" hidden parser: json.Parser = new {} class JsonType { hello: String test: Int } data = parser.parse(read("file:intro.json")) // intro.json has a type mismatch on test, it's a string instead of an int verified: JsonType = data.toTyped(JsonType) ``` <details> <summary>intro.json</summary> { "hello": "world", "test": "oops" } </details> The error I see here is: ``` Expected value of type `Int`, but got type `String`. Value: "oops" 7 | test: Int ^^^ at thing#JsonType.test (file:///thing.pkl, line 7) ``` While this offers a value hint that I can then grep `intro.json` for to find, if you have a sufficiently large JSON file this becomes challenging to rely on for debugging purposes. Some other configuration languages, such as cue have errors that can look like this: ``` verticals.4.categories.767.attributes.0.name: conflicting values "Absinthe style" and "Age group": ./attributes_data.cue:248:8 ./categories_data.cue:119611:10 ./schema.cue:39:14 ./schema.cue:42:16 ``` While this error message isn't fantastic either, it does identify that the problem is with the 5th vertical, and 768th attribute, which gives much higher signal on how to go about dealing with the error. I'd love to see either the parser be smarter about reporting on errors in this fashion, even if it dynamically just references the path of the data that's problematic, or if there's a way we can `pkl import` non pkl files, as an analogue to `pkl eval -f format` so that we can get native PKL error reporting on these issues.

adam referenced this issue

2025-12-30 01:24:17 +01:00

[PR #79] [CLOSED] Create SECURITY.md #400

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/pkl#79

Support better error hints when importing data from Parser sources #79

Support better error hints when importing data from `Parser` sources #79