Adds jq unit

[targodan]

As promised, I'm back. ;)

jq is a powerful json processor, allowing for filtering and manipulation of json data. This PR adds a thin-ish wrapper for the jq python library, allowing a more seamless integration into the binref workflow.

The main difference to the stock jq-cli is support for chunks. Each input chunk is treated individually. Optionally the processed json data can be split into multiple output chunks via the flag --explode. This exploding supports arrays trivially, but can also explode dicts. For each key-value-pair in a dict, one chunk is emitted with the meta variable "json_key" set to the key and the chunk data consisting of the value.

Things to consider

• This adds the dependency "jq"
• As I implemented it, it has an intentional name-clash with the upstream jq command. This is for multiple reasons: (1) because I use binref in a venv, (2) because there is already a hint in the binref readme about possible name clashes and (3) I struggled to come up with a reasonable alias. If you feel uncomfortable adding an intentional name clash, feel free to suggest alternative names. :)

Possible future features

Currently, it can only explode, not join. Maybe, if someone needs it, a future update might be to combine multiple input chunks into one output chunk.

[targodan]

Sooooo, windows support is a bummer 😬

And it does not look like it's going to be happening soon: mwilliamson/jq.py#20

At this point I'm not sure if you want a linux-only unit or if we should maybe delay this until (hoping against hope) windows support comes available in the jq python bindings.

[jhhcs]

It is quite painful to reject such a thorough and well-made PR, but there are a two reasons why that's likely going to happen anyway:

• No Windows support is a complete deal-breaker for me. I want refinery to be honestly and entirely cross-platform.
• There is a generic way to wrap external tools in refinery, using the couple unit. With complex tools that already support point-free style using pipes, I think this is the better and more stable way to interface them.

Once I have found the courage to do so, I will therefore likely close this out without merging it, but as I said, I do so with a heavy heart.

[targodan]

Sorry for the late reply.

No sweat, I completely understand. After all, it's my fault too, since I didn't check windows compatibility of the library. I made the common mistake of assuming. 😉

In order to not make you sweat even more, I'll close the PR myself. No hard feelings. 🙂