undefined | Better HN

0 pointsNateEag3y ago0 comments

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

0 comments

mdaniel3y 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 :-(

NateEagOP3y 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."

j / k navigate · click thread line to collapse