Giters

markbates / configatron

A super cool, simple, and feature rich configuration system for Ruby apps.

Home Page:http://www.metabates.com

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

YAML is terrible and should be driven from the face of the Earth.

bf4 opened this issue · comments

commented

I'd like to hear more about this. I'm giving a talk on YAML later in the year and am very interested in hearing more (of the growing number of) opinions moving away from YAML.

We could chat here or elsewhere, if you're up for it.

commented

Security issues aside (remember what happened to rubygems a few months back?), Ruby keeps changing it's YAML engine out with almost every release making the code around using YAML a real mess. Factor in supporting other implementations like jRuby, Rubinius, etc... and it becomes a real nightmare. I would rather just use JSON or Ruby.

commented

Thanks for the response.

Just thoughts, responses, not advocating a POV, more picking your brain

  • Don't you just mean Syck -> Psych. Now that Psych relies on libyaml/snakeyaml/etc. which implements the YAML spec (which syck didn't), I don't think we should expect substantial library changes again.
  • Certainly YAML is an insecure default, since (via Psych) it allows arbitrary object de-serialization and unlimited symbol generation. For the sake of argument, that can be mitigated by libraries such as safe_yaml and/or future work on Psych.
  • YAML is more portable and parseable (e.g. libyaml) than custom ruby, and natively supports more types and functions than JSON, e.g. below. Do both cases require evaluating external code? Can JSON ever be as easy to read and manage as YAML?
    • JSON has arrays, strings, hashes, numbers, booleans, dates, other js primitives
    • YAML (a superset of JSON) has those plus dates, aliases and merge keys, which are particularly useful

It seems to me that the community is generally moving to replace yaml everywhere with JSON. Rails serializers will just have to figure out a different way to put objects in the database :)

Any thoughts about what to do about rubygems metadata? It does currently require limited object serialization ( see rubygems/rubygems.org@d02c4c0 rubygems/rubygems.org#579 ), but could probably be factored out. Do think configuration files we own are still a reasonable place for yaml, where we can merge in default values? Would you use the YAML/store over pstore?

In other words, 'ok, YAML should be driven from the face of the earth, but where do we start, what steps do we take to change the community / existing code, how can we minimize the cost of change both w/r/t dev time and bugs?'

commented

Google sent me here. 8 years have passed, did you end up doubling down on yaml?