Jsonnet is nice, but not actively developed, unfortunately. I highly recommend you to support UCG [0], which is written in Rust (Jsonnet has two implementations, which is one source of the slowness).
Why are we templating YAML?
321–330 of 351 posts
Re: Why are we templating YAML?
#322Earlier quoted context omitted.
> If you have been around long enough you still remember the world that was excited about XML and templating it using XSLT. As a hindsight it was a horrible world. I actually really like the idea behind XSLT: machine-friendly, human-tolerable, structured data + declarative rules for turning that data into a display, or a report, or whatever else. The execution was horrible though: incredibly verbose, lots of overcomp…
XSLT was one in a litany of domain specific languages (ant, apache rewrite rules, latex macros, etc.) that evolved towards turing completeness because that's what the problem space demanded. In most if not all of these cases an existing and well designed turing complete programming language would likely have better served them.
I wrote a lot of XMLT in early 2000.
The idea behind pure function is nice, but in practice you ended up with hundreds of mini plugins in Java or Python.
Re: Why are we templating YAML?
#323If you have been around long enough you still remember the world that was excited about XML and templating it using XSLT. As a hindsight it was a horrible world. Even though YAML is not optimal, it is a human friendly compromise between too verbose XML and machine only JSON. It lacks native templating, leading to funny constructs e.g. with Ansible files. However human kind has made progress and will make progress fur…
I kinda miss it, actually. XML had many warts, but at least everybody spoke it, and it was the same everywhere. Occasionally you still had some overlapping but different things, like XSD and RELAX NG schemas (though even there, there was a big difference - one is a language for describing data types, and the other is a language for describing grammars). But it's better than several dialects of JSON, YAML, TOML etc. I…
As, I think Douglas Crockford said, the best thing that XML delivered was UTF-8.
Then we have built a whole new domain on things on the top of UTF-8.
Re: Why are we templating YAML?
#324As others in this thread have said: I ask this question all the time, except s/templating/using/. YAML is insanely over complicated; it's as bad or worse than XML for config files, and it doesn't even have the nice streaming mode. Not to mention that it's a bit of a security nightmare (seriously, who put pointers into the YAML spec?). And, on a more subjective note, YAML is just confusing: between all the significant…
> it's as bad or worse than XML for config files Let's agree to disagree here. No human should ever write XML. No human should ever be forced to read it. YAML is very readable and writable if you stay away from the corners. Templating allows you to stay clear of the corners (the 1 char operators that concatenate stuff, b64 stuff and so on).
> the 1 char operators that concatenate stuff
But they're super useful. Some examples from Ansible.
- name: Do something annoying.
command: >
./my-really-annoying-command
-a yep
-c it
--really-does=take-a-lot
--of-options
subcommand
--target=blah
--timeout=60
--callback=/usr/local/bin/callback-x245.sh
https://example.com/this-is-the-worst.aspx
varable_that_I_need_to_preserve_whitespace: |
#BEGIN_LICENSE_KEY
...Re: Why are we templating YAML?
#325Earlier quoted context omitted.
There is already a mechanism to validate the settings.py file inside django. The different context stuff can be handled by using env vars, and a nice python wrapper, like python-decouple.
> There is already a mechanism to validate the settings.py file inside django. It's not exposed, but it's very limited. > The different context stuff can be handled by using env vars, and a nice python wrapper, like python-decouple. It's just one of the way to do it. Go to a new project, they use a different way. The main benefit of Django is the fact that a Django project is well integrated, and you find similar con…
Just so we're on the same page, this is the validation I was referring to -
https://docs.djangoproject.com/en/2.1/topics/checks/
Standardization is always an issue, I guess. Env vars seem to be the norm in the community in my experience, whatever that's worth..
Re: Why are we templating YAML?
#326Earlier quoted context omitted.
Editing JSON is ok without specific format support, it just looks like any other C-like language. Editing YAML is basically impossible without specific support, your editor will almost certainly break any file you open and destroy relevant information on the process.
Care to elaborate? Your statement is hollow on its own. How does your editor destroy information? What kind of information is destroyed? Why is your editor rearranging bits in validly encoded text files?
Most programming editors rearrange the white space of the files they open. Some do it more, some do it less.
Rearranging white space in a YAML file often destroys information.
Re: Why are we templating YAML?
#327Earlier quoted context omitted.
You can just use JSON with comments though. If you have sufficient control over the technology in question to be able to completely change it to a YAML parser, surely you can change it to be a JSON+Comment parser too. See: VS Code's config files.
> You can just use JSON with comments though. Then it's not valid JSON, and if you try to treat it as such bad things will happen.
My point is that if you're in sufficient control of the stack to be able to convert the whole thing over to YAML, you could just as easily convert the whole thing over to JSON+Comments. And of course bad things would happen if you treat JSON+Comments as JSON, but similar bad things would happen if you treat YAML as JSON, so I don't see your point. It's not like people are trying to send their tsconfig's on the wire as "application/json" and expecting arbitrary parsers to support it.
Re: Why are we templating YAML?
#328Earlier quoted context omitted.
You can always use a subset of YAML (much like we do with JavaScript these days).
That's a nice thought, but it comes with its own problems. For example, XMPP uses a sane subset of XML, which is nice, except that people throw full XML parsers at it (because why wouldn't you? Your XML library parses XML and limiting that is more work for the developer to do) and then end up with vulnerabilities they don't know about like entity expansion DOS's or system directive stuff (and YAML has lots of tricky…
We can agree to generate a subset - the things we won't add to a certain stream - even if we are more lax in what we accept by using full parsers.
Re: Why are we templating YAML?
#329Earlier quoted context omitted.
> it's as bad or worse than XML for config files Let's agree to disagree here. No human should ever write XML. No human should ever be forced to read it. YAML is very readable and writable if you stay away from the corners. Templating allows you to stay clear of the corners (the 1 char operators that concatenate stuff, b64 stuff and so on).
> the 1 char operators that concatenate stuff But they're super useful. Some examples from Ansible. - name: Do something annoying. command: > ./my-really-annoying-command -a yep -c it --really-does=take-a-lot --of-options subcommand --target=blah --timeout=60 --callback=/usr/local/bin/callback-x245.sh https://example.com/this-is-the-worst.aspx varable_that_I_need_to_preserve_whitespace: | #BEGIN_LICENSE_KEY ...
But they are less than readable.
Re: Why are we templating YAML?
#330I think they are missing the real selling point of JSON. It's basically interoperable with JavaScript objects. That means you write it, send it, store it, operate on it, etc. with little or no modification. The author says "converting between the two is trivial" which may be true, but the developer overhead is less trivial. And it will always be JSON in the client - JS doesn't support YAML objects.
Except that you cannot encode pretty valid Double.NaN or Date(), which is showstopper for many. I remember mongodb started with json, but switched to in-house bson pretty early because of the json limitations.
Is there anything wrong with just using Date.now() to get a UNIX timestamp to store and then converting it for presentation on the client?