[Request] gojq

[D3vil0p3r]

Requested Package:

gojq

Purpose and Use?

JQ implementation in GO, very useful for parsing any JSON string or file.

Benefits?

* gojq implements nice error messages for invalid query and JSON input. The error message of jq is sometimes difficult to tell where to fix the query.
* gojq supports arbitrary-precision integer calculation while jq does not; jq loses the precision of large integers when calculation is involved.
* jq uses some unstable functions. gojq does not
* jq has several bugs (detailed above) that gojq is not affected.
* gojq allows to read YAML input. jq does not do this.

So, if I need to use jq for arbitrary-precision integer calculation or I need to manipulate YAML input, I cannot do this by jq, but I can do that by gojq.

Builds in clean chroot?

No response

Copyright License?

MIT

Expected interest

More than half.

Prior availability?

No

Is this request unique?

Yes

Is the package banned?

No

More information

No response

[xiota]

Benefits?

No response

What's the benefit/use case for this package over jq ?

[D3vil0p3r]

Benefits?
No response

What's the benefit/use case for this package over jq ?

Here the differences (sorry for the long message):

• gojq is purely implemented with Go language and is completely portable. jq depends on the C standard library so the availability of math functions depends on the library. jq also depends on the regular expression library and it makes build scripts complex.
• gojq implements nice error messages for invalid query and JSON input. The error message of jq is sometimes difficult to tell where to fix the query.
• gojq does not keep the order of object keys. I understand this might cause problems for some scripts but basically, we should not rely on the order of object keys. Due to this limitation, gojq does not have keys_unsorted function and --sort-keys (-S) option. I would implement when ordered map is implemented in the standard library of Go but I'm less motivated.
• gojq supports arbitrary-precision integer calculation while jq does not; jq loses the precision of large integers when calculation is involved. Note that even with gojq, all mathematical functions, including floor and round, convert integers to floating-point numbers; only addition, subtraction, multiplication, modulo, and division operators (when divisible) keep the integer precision. To calculate floor division of integers without losing the precision, use def idivide($n): (. - . % $n) / $n;. To round down floating-point numbers to integers, use def ifloor: floor | tostring | tonumber;, but note that this function does not work with large floating-point numbers and also loses the precision of large integers.
• gojq fixes various bugs of jq. gojq correctly deletes elements of arrays by |= empty (jq#2051). gojq fixes try/catch handling (jq#1859, jq#1885, jq#2140). gojq fixes nth/2 to output nothing when the count is equal to or larger than the stream size (jq#1867). gojq consistently counts by characters (not by bytes) in index, rindex, and indices functions; "１２３４５" | .[index("３"):] results in "３４５" (jq#1430, jq#1624). gojq handles overlapping occurrence differently in rindex and indices; "ababa" | [rindex("aba"), indices("aba")] results in [2,[0,2]] (jq#2433). gojq supports string indexing; "abcde"[2] (jq#1520). gojq accepts indexing query .e0 (jq#1526, jq#1651), and allows gsub to handle patterns including "^" (jq#2148). gojq improves variable lexer to allow using keywords for variable names, especially in binding patterns, also disallows spaces after $ (jq#526). gojq fixes handling files with no newline characters at the end (jq#2374).
• gojq truncates down floating-point numbers on indexing ([0] | .[0.5] results in 0 not null), and slicing ([0,1,2] | .[0.5:1.5] results in [0] not [0,1]). gojq parses unary operators with higher precedence than variable binding ([-1 as $x | 1,$x] results in [1,-1] not [-1,-1]). gojq implements @uri to escape all the reserved characters defined in RFC 3986, Sec. 2.2 (jq#1506), and fixes @base64d to allow binary string as the decoded string (jq#1931). gojq improves time formatting and parsing; deals with %f in strftime and strptime (jq#1409), parses timezone offsets with fromdate and fromdateiso8601 (jq#1053), supports timezone name/offset with %Z/%z in strptime (jq#929, jq#2195), and looks up correct timezone during daylight saving time on formatting with %Z (jq#1912). gojq supports nanoseconds in date and time functions.
• gojq does not support some functions intentionally; get_jq_origin, get_prog_origin, get_search_list (unstable, not listed in jq document), input_line_number, $__loc__ (performance issue), recurse_down (deprecated in jq). gojq does not support some flags; --ascii-output, -a (performance issue), --seq (not used commonly), --sort-keys, -S (sorts by default because map[string]any does not keep the order), --unbuffered (unbuffered by default). gojq does not parse JSON extensions supported by jq; NaN, Infinity, and [000]. gojq normalizes floating-point numbers to fit to double-precision floating-point numbers. gojq does not support or behaves differently with some regular expression metacharacters and flags (regular expression engine differences). gojq does not support BOM (encoding/json does not support this). gojq disallows using keywords for function names (def true: .; true is a confusing query), and module name prefixes in function declarations (using module prefixes like def m::f: .; is undocumented).
• gojq supports reading from YAML input (--yaml-input) while jq does not. gojq also supports YAML output (--yaml-output). gojq supports a few filters missing in jq; scan/2 (jq#2207), and @urid format string (jq#2261).

[xiota]

I was asking about benefits, not differences. Why build and use gojq when it's easier to get jq from the standard repository? Most of the changes in the list don't matter to end users (implementation language and details) or would be reasons to avoid gojq (intentionally missing functionality).

I'm also interested in use cases. Describe scenarios in which you chose gojq over jq and why you made that decision.

[D3vil0p3r]

Consider that dealing with JSON strings is not easy. For me, as a technical person, those differences are almost all benefits. jq has some limits. I try to explain in "human" high-level the benefits:

* gojq implements nice error messages for invalid query and JSON input. The error message of jq is sometimes difficult to tell where to fix the query.
* gojq supports arbitrary-precision integer calculation while jq does not; jq loses the precision of large integers when calculation is involved.
* jq uses some unstable functions. gojq does not
* jq has several bugs (detailed above) that gojq is not affected.
* gojq allows to read YAML input. jq does not do this.

So, if I need to use jq for arbitrary-precision integer calculation or I need to manipulate YAML input, I cannot do this by jq, but I can do that by gojq.

[xiota]

So, if I need to use jq for arbitrary-precision integer calculation or I need to manipulate YAML input, I cannot do this by jq, but I can do that by gojq.

Thank you. Would be helpful to include info like this in requests.

[D3vil0p3r]

Now added in the description.