I also hate YAML 😅 I think Circle uses it because Travis uses it, because Rails uses it.

So we can blame DHH really.

:)

@marc-omorain Maybe it's time to update your profile description? :)

Ya, sure I can lend a hand there. Sign me up!

Thanks! ❤️ I've given you admin access and added you to https://github.com/clj-commons/clj-yaml/blob/master/.github/CODEOWNERS

I find YAML annoying too. I tend to struggle when I have to use it but never really read any details about it. Thus thread just lead me to google which lead me to learn that you can use node anchors in YAML. Huh!

@lee There are many "interesting" bits in YAML. I think the most pressing issue is this one now: https://github.com/clj-commons/clj-yaml/issues/35

This caused a breaking change 😱

The Snake YAML maintainer is a character.

But...but... we don't have breaking changes in Clojure!?!

@lee That's the thing: we could "fix" this in the clj-yaml lib. So the dilemma is: follow the (crazy) YAML 1.1 spec or protect people from this breaking change

I submitted a patch to fix a NPE in SnakeYaml a few years back. He accepted the patch and said a new version would be released in 6 months time.

Hey @marc-omorain? We miss ya!

He only releases twice a year. 🤷

Yeah, that guy...

I think people who have invented YAML come from a different universe

He seems maybe a bit on the gruff side.

Wouldn’t you be too if your hobby was to maintain a YAML parser?

Maybe also a cultural difference...

Ha! Probably @slipset!

http://yaml.org lists other java implementations:

Java:
  - SnakeYAML Engine  # Java 8+ / YAML 1.2
  - SnakeYAML         # Java 5 / YAML 1.1
  - YamlBeans         # To/from JavaBeans. YAML 1.0/1.1
  - eo-yaml           # YAML 1.2 for Java 8. Packaged as a Module (Java 9+)
  - Chronicle-Wire    # Java Implementation

sure, but clj-yaml is built on snakeyaml, you can't easily change that. maybe we're able to get away with moving to snakeyml engine, don't know

Ok, ramping up on yaml octals.... https://www.infoworld.com/article/3669238/7-yaml-gotchas-to-avoidand-how-to-avoid-them.html#toc-4

So YAML 1.2 is a breaking change from YAML 1.1?

of course, what did you expect, backwards compatibility with a minor version number update?

Ha! Ok, weird reality.

The changes might be for the better in 1.2 though and I don't think it will affect many programs: https://yaml.readthedocs.io/en/latest/pyyaml.html#defaulting-to-yaml-1-2-support

but you never know of course

I think many tools are stuck on 1.1

I can ramp up on this issue if that helps. At the very least we'd have one more person who has a better understanding.

@lee yes please! My preliminary proposal was to add an option to control the weird octal parsing

this can be done using a custom Resolver, or so but I haven't really looked

Ok, I'll take a look-see.

I take back my “gruff” judgement, I think it was unfair.

Well, I'm certainly a gruff sometimes, aren't we all on some days

> Wouldn’t you be too if your hobby was to maintain a YAML parser? This made me snort.

I think I was gruff to say he was gruff.

For what it's worth, I actually don't care about parsing. I care about emitting.

(see https://bitbucket.org/snakeyaml/snakeyaml/issues/550/regressing-in-handling-number-like-strings#comment-64102182 for the sad, sad details)

@U0EHU1800 I spent a fair bit of time looking at this today. https://github.com/clj-commons/clj-yaml/issues/35#issuecomment-1248444895 https://github.com/clj-commons/clj-yaml/issues/35#issuecomment-1248656393

cheers. this whole thing is hateful, so I appreciate the diligence and attention to detail.

I think you made a good argument there btw!

(I think gmail broke for me, so I'm no longer receiving email updates to all of this wonderful discussion, so thanks for pointing me to these updates)

Does the resolver handle dumping as well?

Don’t think so. My current understanding is that we could create a custom resolver to ignore octals. Have not tried it yet, I guess they would default to strings.

Andrey said we might want to look at timestamps too, but I’m not sure why yet.

For my really limited use-case, I'm dumping values via snakeyaml/clj-yaml/babashka (YAML 1.1) and reading them using js-yaml (YAML 1.2) (in CDK). One of our AWS accounts has a leading zero. AWS account ids are number-like strings, so that one with a leading 0 is being emitted without quotes by clj-yaml and being read as a number in js-yaml, dropping the 0 (and being a number)

So, for me, the snakeyaml/clj-yaml resolver/parser never enters into the picture.

Ah. So is js-yaml maybe using yaml 1.2?

It definitely is. And they noted the behavior difference in one of their updates.

Hmm… that was a nasty booboo with the octals in yaml 1.1 spec. And breaking change in yaml 1.2 spec.

https://github.com/nodeca/js-yaml/blob/ab31bba6b41f58390f431123ffec5031b986edf5/migrate_v3_to_v4.md#loading-in-v4-documents-previously-dumped-in-v3

Yeah. Rich's Spec-u-lation talk really crystalized so much of those ideas for me back in the day. Hard for me to see things any other way at this point. Well, I can see it, I just can't bring myself to agree that it's a good idea to have breaking changes.

Smart Fellah that Mr Hickey!

Hammocks all around.

@U0EHU1800 Awesome reply in that repo, I admire your patience

I'm cautiously optimistic. I don't see any indication that any PR wouldn't be rejected outright based on principle that things are just find as they currently are in 1.30, but then again I don't see any indication that it necessarily would be either. I can't tell whether he's sympathetic to any of the arguments I put forward.

Given the 6 month release cadence I'd say we will fix it in clj-yaml anyhow?

So, now the question for me is whether to put the time in to learn the snakeyaml code well enough to make a reasonable PR. My immediate use-case can be avoided by switching to json. I do think it's a regression in the upstream library so ideally I'd provide the fix there for The Good of All™ (😆).

Good point re: release cycle and fixing it for now. I was trying to figure out how that would be done in clj-yaml. I'm not sure how to override the provided emitter behavior. Maybe override the representer? I was looking a bit last night and it wasn't immediately obvious.

I'd love to see it being fixed in snakeyaml

you could find the commit that caused the regression to see how to fix it maybe?

Does anyone want to write their own YAML parser ?

Joking but also not joking.

as a hobby?

Yeah, but it depends on the scope. Writing a JSON parser is pretty easy. I've written a few in the past for fun. That wouldn't daunt me. Writing a YAML parser is probably a horrifically large task.

I was referring to the gruff part before when I said as a hobby ;)

I have considered it, but no

The only reason I care about clj-commons/clj-yaml is that its part of bb and I don't want bb to behave wrong with respect to people's builds

but I'm not that invested in yaml that I actually want to put that much time in it

I mean, getting the first 80% right is probably easy. But then becoming spec-compliant with all the quirks is where it gets "fun"

Oh yes. So many quirks I bet. The CircleCI Yaml loader has to check for things like loops, which are possible in YAML.

clj-yaml supports those loops via lazy-seqs ;)

We also had a bug where someone was able to create a map with two keys, both of which were null, with 2 values, which were also null.

done