Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dear GitHub: no YAML anchors, please

blog.yossarian.net

Post reply on HN
Print view View original

61–70 of 159 posts

Re: Dear GitHub: no YAML anchors, please

#61

Post by true_blue »

phanimahesh wrote: post #46
TheDong wrote: post #14

Earlier quoted context omitted.

Wanna DRY out your github actions yaml? Generate it from Dhall, or cue, or python, or some real language that supports actual abstractions. If your problem is you want to DRY out yaml, and you use more yaml features to do it, you now have more problems, not fewer.

This. So true. Yaml has always been an overly complicated format, with weird quirks ( like norway becoming false in a list of country codes ). I find it an absolute shame that languages like Dhall did not become more popular earlier. Now everything in devops is yaml, and I think many developers pick yaml configs not out of good reasons but defaulting to its ubiquity as sufficient.

>norway

yaml 1.2 was released in 2009, and it fixed this problem. this is an implementation issue.

https://yaml.org/spec/1.2.2/#12-yaml-history

Re: Dear GitHub: no YAML anchors, please

#62

Post by woodruffw »

btreecat wrote: post #56
woodruffw wrote: post #45

Earlier quoted context omitted.

To be clear, I understand why people want to use anchors. The argument isn't that they aren't useful: it's that the juice is not worth the squeeze, and that GitHub's decision to support them reflects a lack of design discretion. Or in other words: if your problem is DRYness, GitHub should be fixing or enhancing the ~dozen other ways in which the components of a workflow shadow and scope with each other. Adding a new…

So GitHub shouldn't implement the spec because you personally don't like that the spec solves a problem you can optionally solve at another layer?

No; GitHub shouldn't support YAML anchors because it's a deviation from the status quo, and the argument is specifically that the actions ecosystem doesn't need to make analysis any harder than it already is.

(As the post notes, neither I nor GitHub appears to see full compliance with YAML 1.1 to be an important goal: they still don't support merge keys, and I'm sure they don't support all kinds of minutiae like non-primitive keys that make YAML uniquely annoying to analyze. Conforming to a complex specification is not inherently a good thing; sometimes good engineering taste dictates that only a subset should be implemented.)

Re: Dear GitHub: no YAML anchors, please

#63

Post by Perz1val »

TheDong wrote: post #25
red_hare wrote: post #17

Earlier quoted context omitted.

I'm surprised by this take. I love YAML for this use case. Easy to write and read by hand, while also being easy to write and read with code in just about every language.

> Easy to write and read by hand, while also being easy to write and read with code in just about every language Language implementations for yaml vary _wildly_. What does the following parse as: some_map: key: value no: cap If I google "yaml online" and paste it in, one gives me: {'some_map': {False: 'cap', 'key': 'value'}} The other gives me: {'some_map': {'false': 'cap', 'key': 'value'}} ... and neither gives what…

The classic Norway bug

Re: Dear GitHub: no YAML anchors, please

#64

Post by VGHN7XDuOXPAzol »

woodruffw wrote: post #53
detaro wrote: post #44

Earlier quoted context omitted.

in what ways do they make static analysis harder? Don't they flatten out trivially after parsing?

The flattening out is the problem: most (all?) widely used YAML parsers represent the YAML document using the JSON object model, which means that there's no model or element representation of the anchors themselves. That in turn means that there's no way to construct a source span back to the anchor itself, because the parsed representation doesn't know where the anchor came from (only that it was flattened).

This is something that a custom parser library could figure out, no? The same as how you have format-preserving TOML libraries, for instance.

I think it makes way more sense for GitHub to support YAML anchors given they are after all part of the YAML spec. Otherwise, don't call it YAML! (This was a criticism of mine for many years, I'm very glad they finally saw the light and rectified this bug)

Re: Dear GitHub: no YAML anchors, please

#65

Post by btreecat »

woodruffw wrote: post #62
btreecat wrote: post #56

Earlier quoted context omitted.

So GitHub shouldn't implement the spec because you personally don't like that the spec solves a problem you can optionally solve at another layer?

No; GitHub shouldn't support YAML anchors because it's a deviation from the status quo, and the argument is specifically that the actions ecosystem doesn't need to make analysis any harder than it already is. (As the post notes, neither I nor GitHub appears to see full compliance with YAML 1.1 to be an important goal: they still don't support merge keys, and I'm sure they don't support all kinds of minutiae like non-…

> No; GitHub shouldn't support YAML anchors because it's a deviation from the status quo, and the argument is specifically that the actions ecosystem doesn't need to make analysis any harder than it already is. > > (As the post notes, neither I nor GitHub appears to see full compliance with YAML 1.1 to be an important goal: they still don't support merge keys, and I'm sure they don't support all kinds of minutiae like non-primitive keys that make YAML uniquely annoying to analyze. Conforming to a complex specification is not inherently a good thing; sometimes good engineering taste dictates that only a subset should be implemented.)

That's a long way to say "yes, actually"

Re: Dear GitHub: no YAML anchors, please

#66

Post by woodruffw »

beder wrote: post #59

A very pedantic point, but merge keys are not part of the YAML spec [1]! Merge keys are a custom type [2], which may optionally be applied during the construction phase of loading. I definitely wouldn't say that merge keys are integral to anchors. (Also, as a personal bias, merge keys are really bad because they are ambiguous, and I haven't implemented them in my C++ yaml library (yaml-cpp) because of that.) [1]: htt…

Yeah, I find the situation here very confusing: I agree that merge keys are not part of YAML 1.2, but they are part of YAML 1.1. The reason they don't appear to be in the "main" 1.1 spec itself is because they were added to 1.1 after 1.1 was already deprecated[1].

[1]: https://ktomk.github.io/writing/yaml-anchor-alias-and-merge-...

Re: Dear GitHub: no YAML anchors, please

#67

Post by woodruffw »

btreecat wrote: post #65
woodruffw wrote: post #62

Earlier quoted context omitted.

No; GitHub shouldn't support YAML anchors because it's a deviation from the status quo, and the argument is specifically that the actions ecosystem doesn't need to make analysis any harder than it already is. (As the post notes, neither I nor GitHub appears to see full compliance with YAML 1.1 to be an important goal: they still don't support merge keys, and I'm sure they don't support all kinds of minutiae like non-…

> No; GitHub shouldn't support YAML anchors because it's a deviation from the status quo, and the argument is specifically that the actions ecosystem doesn't need to make analysis any harder than it already is. > > (As the post notes, neither I nor GitHub appears to see full compliance with YAML 1.1 to be an important goal: they still don't support merge keys, and I'm sure they don't support all kinds of minutiae lik…

> That's a long way to say "yes, actually"

"Because I don't like it" makes it sound like I don't have a technical argument here, which I do. Do you think it's polite or charitable to reduce peoples' technical arguments into "yuck or yum" statements like this?

Re: Dear GitHub: no YAML anchors, please

#68

Post by [deleted] »

btreecat wrote: post #56
woodruffw wrote: post #45

Earlier quoted context omitted.

To be clear, I understand why people want to use anchors. The argument isn't that they aren't useful: it's that the juice is not worth the squeeze, and that GitHub's decision to support them reflects a lack of design discretion. Or in other words: if your problem is DRYness, GitHub should be fixing or enhancing the ~dozen other ways in which the components of a workflow shadow and scope with each other. Adding a new…

So GitHub shouldn't implement the spec because you personally don't like that the spec solves a problem you can optionally solve at another layer?

[deleted]

Re: Dear GitHub: no YAML anchors, please

#69

Post by VGHN7XDuOXPAzol »

woodruffw wrote: post #62
btreecat wrote: post #56

Earlier quoted context omitted.

So GitHub shouldn't implement the spec because you personally don't like that the spec solves a problem you can optionally solve at another layer?

No; GitHub shouldn't support YAML anchors because it's a deviation from the status quo, and the argument is specifically that the actions ecosystem doesn't need to make analysis any harder than it already is. (As the post notes, neither I nor GitHub appears to see full compliance with YAML 1.1 to be an important goal: they still don't support merge keys, and I'm sure they don't support all kinds of minutiae like non-…

> Conforming to a complex specification is not inherently a good thing

Kind of a hard disagree here; if you don't want to conform to a specification, don't claim that you're accepting documents from that specification. Call it github-flavored YAML (GFY) or something and accept a different file extension.

https://github.com/actions/runner/issues/1182

> YAML 1.1 to be an important goal: they still don't support merge keys

right, they don't do merge keys because it's not in YAML 1.2 anymore. Anchors are, however. They haven't said that noncompliance with YAML 1.2 spec is intentional

Re: Dear GitHub: no YAML anchors, please

#70

Post by imcritic »

I think the author is nuts.

First, he can just not use the feature, not advocate for its removal.

Second, his example alternative is wrong: it would set variables for all steps, not just those 2, he didn't think of a scenario where there are 3 steps and you need to have common envs in just 2 of them.

Post reply on HN