Our great sponsors
-
jc
CLI tool and python library that converts the output of popular command-line tools, file-types, and common strings to JSON, YAML, or Dictionaries. This allows piping of output to tools like jq and simplifying automation scripts.
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
dasel
Select, put and delete data from JSON, TOML, YAML, XML and CSV files with a single tool. Supports conversion between formats and can be used as a Go package.
-
libxo
The libxo library allows an application to generate text, XML, JSON, and HTML output using a common set of function calls. The application decides at run time which output style should be produced.
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
Some alternative ideas for making JSON more readable:
- Pipe into gron (https://github.com/tomnomnom/gron) to get a `foo.bar.baz = val` kind of syntax.
- Pipe into visidata (https://www.visidata.org/) to get a spreadsheet-like editable view.
This is one of many inherent issues with using unstructured text as an API. That's why I believe there should be a JSON (or at least some other widely used format[1]) option for tools that have output that would be useful in scripts.
[0] https://github.com/kellyjonbrazil/jc#locale
[1] formats should have good library support across many languages and nice filter/query capabilities from the command-line
This is great!
I am the author of SPyQL [1]. Combining JC with SPyQL you can easily query the json output and run python commands on top of it from the command-line :-) You can do aggregations and so forth in a much simpler and intuitive way than with jq.
I just wrote a blogpost [2] that illustrates it. It is more focused on CSV, but the commands would be the same if you were working with JSON.
[1] https://github.com/dcmoura/spyql
There's a clash of names between this jc and autojump (https://github.com/wting/autojump) jc (jump to child)
Can you trust it? Cli tool output is not exactly stable. I thought that's why libxo exists?
https://github.com/Juniper/libxo
But python is also universal? You can just bundle jc inside https://github.com/jart/cosmopolitan/tree/master/third_party... and it's as universal as it gets.
A plain Jevko parser simply turns your unicode sequence into a tree which has its fragments as leaves/labels.
No data types on that level, much like in XML.
Now above that level there is several ways to differentiate between them.
The simplest pragmatic way is a kind of type inference: if a text parses as a number, it's a number, if it's "true" or "false", it's a boolean. Otherwise it's a string. If you know the implicit schema of your data then this will be sufficient to get the job done.
Otherwise you employ a separate schema -- JC in particular has per-parser schemas anyway, so that's covered in this case.
Or you do "syntax-driven" data types, similar to JSON, e.g. strings start w/ "'".
Here is a shitty demo: https://jevko.github.io/interjevko.bundle.html
It shows schema inference from JSON and the schemaless (syntax-driven) flavor.
Jevko itself is stable and formally specified: https://github.com/jevko/specifications/blob/master/spec-sta...
It's very easy to write a parser in any language (I've written one in several) and from there start using it.
However, I am still very much working on specifications for formats above Jevko. I have some recent implementations of the simplest possible format which converts Jevko to arrays/objects/strings:
* https://github.com/jevko/easyjevko.lua
You can also run `jc -h --dig` to get the parser details that include the schema.
Having true JSON Schema[0] is being considered, but on the back-burner due to the sheer number of parsers to build schemas for. Also, it is more difficult to accurately define the schema for a small subset of parsers since their command output are so variable.
[0] https://json-schema.org/
Related posts
- jq help: is it possible to replace a key-value in one json file using the data from another json file?
- How to Deploy a Fast API Application to a Kubernetes Cluster using Podman and Minikube
- Analysing FastAPI Middleware Performance
- Show HN: Mutuple – Replace items in Python's "immutable" tuples
- Autojump: A CD command that learns