I added a std.format_json function, and that required making the width
in the pretty-printer optional. With that in place, it is now easier to
support the JSON Lines format, something I wanted to do for some time
already.
This is a first step to accept the new format in the CLI. It does not
implement the formatting itself yet.
I want to use Ninja for keeping repositories of files generated by RCL
up to date. But then Ninja needs to know when to rebuild. It can do this
with depfiles. I only need to generate them.
I need --output to be able to specify an output file to write to. At
least, that is the common thing to call it. And also, I was calling the
format "format" already internally and in the docs. I think this is a
bit more logical.
In some circles it is common to put multiple yaml documents in one file,
for example with Kubernetes manifests. You can already render a
Kubernetes manifest by just exporting as json, but then you can't do
these multi-document files. So add special support for that.
At some point it may be nice to output "friendlier" yaml, but I don't
want to go there at this point. The toml was messy enough already.
I've needed this a few times, when I want to print a table from json
values. It's not too difficult to add. This implementation is somewhat
inefficient because it constructs and then formats an intermediate Doc
while it could print straight to stdout, but this does make the output
modes more uniform, and it makes it slightly easier to report errors
about non-formattable values. Also, the overhead is no worse than json
output, which so far has been fine for me if the document is not
humongous.
I just had an idea: instead of providing the state of stdin as an input
to the CLI parser, simplify the CLI parser (and tests) enormously by
removing that again, but instead, when it picks stdin as the file,
distinguish between "stdin (explictly)" and "stdin (default)".
Then in the input handling, I had another idea to make things simpler
without being a complete footgun to newcomers: default to stdin always,
regardless of whether stdin is a TTY. But, when stdin was chosen by
default and it is a TTY, print an informational message to stderr to
point out to users that we're waiting for input from stdin.
This also includes docs for the CLI for sandboxing modes, which at
this point are completely hypothetical, as well as relative and
workdir-relative import paths, which are also not implemented. One
might call it "readme-driven development".
