3 ms·

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 too

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 5y 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."