Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Inconsistent Function Manifestation as JSON Across Jsonnet Implementations #201

Closed
ys-db opened this issue Feb 17, 2024 · 1 comment
Closed

Comments

@ys-db
Copy link

ys-db commented Feb 17, 2024

Hello,

I’ve encountered an intriguing inconsistency in how functions are converted to JSON across different Jsonnet implementations, specifically between Go/C++, and sjsonnet.

Issue Description

Attempting to manifest a function as JSON output reveals a discrepancy in behavior. The sjsonnet implementation successfully evaluates and converts the function into JSON, whereas the Go and C++ implementations reject it, producing an error.

Code Snippet

❯ sjsonnet -e 'local f() = {v:42};{f:f}'
{
   "f": {
      "v": 42
   }
}

Expected Behavior

Both implementations should ideally align with their handling of function-to-JSON conversion, following the Jsonnet specification closely.

Error in Go Implementation

❯ jsonnet -e 'local f() = {v:42};{f:f}'
RUNTIME ERROR: couldn't manifest function as JSON
	Field "f"
	During manifestation

Related Observation

When modifying the function f to accept a parameter, sjsonnet produces a different error. While C++/Go implementations produce the same error.

Code Snippet with Parameter

❯ sjsonnet -e 'local f(x) = {v:x};{f:f}'
sjsonnet.Error: Function parameter x not bound in call
    at .((materialize) offset:)

Questions

  • Is this behavior (specifically the acceptance of function-to-JSON conversion in sjsonnet) intended and defined within the language spec?

The inconsistent behavior is confusing to users. Understanding this would ensure jsonnet is portable and behaves predictably across environments.

@ys-db
Copy link
Author

ys-db commented Feb 17, 2024

duplicate of #168

@stephenamar-db stephenamar-db closed this as not planned Won't fix, can't repro, duplicate, stale Dec 11, 2024
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants