5 ms·

There is also "JP" https://github.com/jmespath/jp https://github.com/jmespath/jp which follows the jmespath standard

mdaniel 4y ago
My heartburn with jmespath is that it lacks pipelines, only projections, so doing _crazy_ stuff to the input structure is damn near impossible
- NateEag 4y ago
  I suspect the JMESPath people would argue that if you want to do major transformations to the input, you should write a proper program, and that a CLI query tool should focus on, well, querying. I'm personally trying to move away from jq and towards jp, because - there's a standard defining it, not just an implementation, decreasing the odds of being stuck with an unmaintained tool - there are libraries supporting the syntax for most of the major programming languages - JMESPath's relative simplicity compared to jq is a good thing, IMO - Turing-completeness is a two-edged sword - JMESPath is the AWS CLI query language, which is a convenient bonus
  - mdaniel 4y ago
    > JMESPath is the AWS CLI query language, which is a convenient bonus And in ansible, too, FWIW, but yes it's my hand-to-hand combat with the language in both of those circumstances that has formed my opinion about it Regrettably, "kubectl get -o jsonpath" is _almost_ the same, but just different enough to trip me up :-(
    - NateEag 4y ago
      Despite using Ansible for several different projects in the past few years, I had no idea there was a corner involving JMESPath. Thanks for the heads-up. FWIW, my choice to move towards JMESPath is definitely a pragmatic one, not an aesthetic preference. I can't say JMESPath fills me with joy, and the syntax does not come naturally to me - it just solves the problem acceptably well and in a way that has some network effects. I have plenty of respect for "I've used this tool in the wild and the experience was unpleasant."
- remram 4y ago
  From a computer science point of view, what kind of transformations are impossible to express in jmespath but are possible in jq?
  - mdaniel 4y ago
    I dunno how to speak to your "computer science" part, but pragmatically anything that requires a "backreference", because unlike with JSONPath (and, of course, jq) there are no "root object" references $ printf '{"a": {"b":"c", "d":["d0","d1"]}}' | jq -r '[ .a as $a | $a.d[] | {x: ., y: $a.b}]' [ { "x": "d0", "y": "c" }, { "x": "d1", "y": "c" } ] and I realize this isn't as pure CS-y as you were asking, but this syntax is hell on quoting $ printf '["a","b"]' | jp -u 'join(`"\n"`, @)' # vs $ printf '["a","b"]' | jq -r 'join("\n")'
    - remram 4y ago
      I see. The need to quote JSON values and the need for @ seem like a high price to pay for removing the . in field accesses. I also find jq more intuitive but I really dislike that we have three standards each used by a number of tools, e.g. jsonpath, jmespath, and jq.

My heartburn with jmespath is that it lacks pipelines, only projections, so doing _crazy_ stuff to the input structure is damn near impossible

NateEag 4y ago
I suspect the JMESPath people would argue that if you want to do major transformations to the input, you should write a proper program, and that a CLI query tool should focus on, well, querying. I'm personally trying to move away from jq and towards jp, because - there's a standard defining it, not just an implementation, decreasing the odds of being stuck with an unmaintained tool - there are libraries supporting the syntax for most of the major programming languages - JMESPath's relative simplicity compared to jq is a good thing, IMO - Turing-completeness is a two-edged sword - JMESPath is the AWS CLI query language, which is a convenient bonus
- mdaniel 4y ago
  > JMESPath is the AWS CLI query language, which is a convenient bonus And in ansible, too, FWIW, but yes it's my hand-to-hand combat with the language in both of those circumstances that has formed my opinion about it Regrettably, "kubectl get -o jsonpath" is _almost_ the same, but just different enough to trip me up :-(
  - NateEag 4y ago
    Despite using Ansible for several different projects in the past few years, I had no idea there was a corner involving JMESPath. Thanks for the heads-up. FWIW, my choice to move towards JMESPath is definitely a pragmatic one, not an aesthetic preference. I can't say JMESPath fills me with joy, and the syntax does not come naturally to me - it just solves the problem acceptably well and in a way that has some network effects. I have plenty of respect for "I've used this tool in the wild and the experience was unpleasant."
remram 4y ago
From a computer science point of view, what kind of transformations are impossible to express in jmespath but are possible in jq?
- mdaniel 4y ago
  I dunno how to speak to your "computer science" part, but pragmatically anything that requires a "backreference", because unlike with JSONPath (and, of course, jq) there are no "root object" references $ printf '{"a": {"b":"c", "d":["d0","d1"]}}' | jq -r '[ .a as $a | $a.d[] | {x: ., y: $a.b}]' [ { "x": "d0", "y": "c" }, { "x": "d1", "y": "c" } ] and I realize this isn't as pure CS-y as you were asking, but this syntax is hell on quoting $ printf '["a","b"]' | jp -u 'join(`"\n"`, @)' # vs $ printf '["a","b"]' | jq -r 'join("\n")'
  - remram 4y ago
    I see. The need to quote JSON values and the need for @ seem like a high price to pay for removing the . in field accesses. I also find jq more intuitive but I really dislike that we have three standards each used by a number of tools, e.g. jsonpath, jmespath, and jq.