I know, right? I've switched to using jp: its syntax is based on an actual standard and it clicks much more with me than jq's syntax.

https://github.com/jmespath/jp

Playing with `jp` a bit, I still like it, but it's very frustrating to do updates in place.

For example, I wanted to write a simple expression to delete outputs from an ipython notebook.

    {
        "cells": [{
            "stuff": "blah blah",
            "outputs": ["crap", "to", "delete"]
        }], "other stuff": "blah blah"
    }

The simplest expression I could come up with was:

    merge(@, {
      "cells": map(
        &merge(@, {"outputs": `[]`}),
        cells[]
      )
    })

And that's verbose because you're reconstructing the structure.

In fairness, it's impressive that the language can express it at all, given it's a query language.

Maybe the real answer is to denote a subset of JMESPath that is guaranteed to return assignable nodes, that is only selects, slices, filters, etc. Then you run the query and perform assignments against those.

Nice! I didn’t actually realise JMESPath was a standard, I first came across it in the AWS CLI and definitely found it nicer than jq. Good to avoid trying to learn both.

Thanks for this suggestion. I too also have problems dealing with jq syntax. jp looks a lot more intuitive.