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

91–100 of 159 posts

Re: Dear GitHub: no YAML anchors, please

#91

Post by danudey »

Wrote a new yaml grepping tool this past weekend and just realized thanks to this that I have a whole new can of worms to keep in mind. Ugh.

Turns out it does report values at their targets (which is desirable) but doesn't know or indicate that they're anchors (undesirable).

Also tested something with yq - if you tell it to edit a node that is actually from a yaml anchor, it updates the original anchor without warning you that that's what you're doing. Yikes.

(For anyone who wants to test it: https://pypi.org/project/yamlgrep/)

Re: Dear GitHub: no YAML anchors, please

#92

Post by nirvdrum »

baq wrote: post #89
nirvdrum wrote: post #82

Earlier quoted context omitted.

Oh, for goodness' sake. We know YAML syntax and that's the only part that's relevant here. Pointing out that different software uses different keys for their configuration or even takes different actions for keys that happen to share the same name isn't particularly insightful. We haven't been bamboozled.

I don’t understand even more now. If you freely admit they’re different languages, the only reason to keep using the stupid deficient syntax is momentum, and while it isn’t a bad reason, it is costing you and everyone else in the long run.

Huh? I'm using YAML because that's the language used to configure GitHub Actions. You may not like YAML, and that's fine. But if we collectively had to learn the unique way each project generates their GitHub Actions config, that would be a massive waste of time.

YAML isn't that hard. Most GitHub Actions configs I see are well under 500 lines; they're not crumbling under the weight of complexity.

Re: Dear GitHub: no YAML anchors, please

#93

Post by tkfu »

true_blue wrote: post #61
phanimahesh wrote: post #46

Earlier quoted context omitted.

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

I would not say it "fixed" the problem. It removed the _recommendation_ for parser implementations to use the regex `y|Y|yes|Yes|YES|n|N|no|No|NO|true|True|TRUE|false|False|FALSE|on|On|ON|off|Off|OFF` for parsing scalars as bools, it changed the _canonical_ presentation of bools from `y|n` to `true|false`, and it introduced the "schema" concept. It also introduced and recommended the use of the Core Schema, which uses `true|True|TRUE|false|False|FALSE` as the regex for inferring bools from scalars. But unsurprisingly, since using this schema is only a recommendation and not a requirement, many implementations elected to keep their backwards-compatible implementations that use the original regex.

So the Norway problem persists.

Re: Dear GitHub: no YAML anchors, please

#94

Post by tkfu »

TheDong wrote: post #84
true_blue wrote: post #61

Earlier quoted context omitted.

>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

If your data format is so complicated that all commonly used implementations are not compliant with your spec, maybe it's a problem with the data-format. Every single implementation people actually use seems to be a messy mix of yaml 1.1 and 1.2.... Maybe if the yaml project wants to consider this fixed, they should have written some correct reference parsers themselves for any languages in need, and encouraged their…

I noted this in reply to the comment above, but: the YAML 1.2 spec doesn't actually mandate that parsers use the Core Schema. They left it as a recommendation. So I don't consider it to be "fixed" at all.

Re: Dear GitHub: no YAML anchors, please

#95

Post by time4tea »

pacoWebConsult wrote: post #12

Can YAML go away entirely and instead allow pipelines to be defined with an actual language? What benefits does the runner-interpreted yaml-defined pipeline paradigm actually achieve? Especially with runners that can't be executed and tested locally, working with them is a nightmare.

Have you seen https://typeflows.io/

It takes your programming language version and turns it into github actions yaml, so you dont need to do any of that sort of thing.

Re: Dear GitHub: no YAML anchors, please

#96

Post by Levitating »

time4tea wrote: post #95
pacoWebConsult wrote: post #12

Can YAML go away entirely and instead allow pipelines to be defined with an actual language? What benefits does the runner-interpreted yaml-defined pipeline paradigm actually achieve? Especially with runners that can't be executed and tested locally, working with them is a nightmare.

Have you seen https://typeflows.io/ It takes your programming language version and turns it into github actions yaml, so you dont need to do any of that sort of thing.

Website barely loads on my old phone and I can't see any examples of the syntax.

Re: Dear GitHub: no YAML anchors, please

#97

Post by herpdyderp »

time4tea wrote: post #95
pacoWebConsult wrote: post #12

Can YAML go away entirely and instead allow pipelines to be defined with an actual language? What benefits does the runner-interpreted yaml-defined pipeline paradigm actually achieve? Especially with runners that can't be executed and tested locally, working with them is a nightmare.

Have you seen https://typeflows.io/ It takes your programming language version and turns it into github actions yaml, so you dont need to do any of that sort of thing.

It has pricing tiers!? That's crazy, just use https://www.npmjs.com/package/github-actions-workflow-ts

Re: Dear GitHub: no YAML anchors, please

#98

Post by [deleted] »

pacoWebConsult wrote: post #12

Can YAML go away entirely and instead allow pipelines to be defined with an actual language? What benefits does the runner-interpreted yaml-defined pipeline paradigm actually achieve? Especially with runners that can't be executed and tested locally, working with them is a nightmare.

[deleted]

Re: Dear GitHub: no YAML anchors, please

#99

Post by iLoveOncall »

jayd16 wrote: post #60
pacoWebConsult wrote: post #12

Can YAML go away entirely and instead allow pipelines to be defined with an actual language? What benefits does the runner-interpreted yaml-defined pipeline paradigm actually achieve? Especially with runners that can't be executed and tested locally, working with them is a nightmare.

Why do we think an arbitrary language is easier to reason about? If it was so easy you could just do it now. The yaml could be extremely simple and just call into your app, but most don't bother. I'm certainly willing to believe that yaml is not the ideal answer but unless we're comparing it to a concrete alternative, I feel like this is just a "grass is always greener" type take.

There is a battle tested example of YAML vs programming languages in CloudFormation templates vs CDK.

I don't think anybody serious has any argument in favor of CloudFormation templates.

Re: Dear GitHub: no YAML anchors, please

#100

Post by easterncalculus »

wiether wrote: post #47
pacoWebConsult wrote: post #12

Can YAML go away entirely and instead allow pipelines to be defined with an actual language? What benefits does the runner-interpreted yaml-defined pipeline paradigm actually achieve? Especially with runners that can't be executed and tested locally, working with them is a nightmare.

Basically what we ended up doing at work is creating some kind of YAML generator. We write Bash or Python, and our tool will produce the YAML pipeline reflecting it. So we dont need to maintain YAML with over-complicated format. The resulting YAML is not meant to be read by an actual human since its absolute garbage, but the code we want to run is running when we want, without having to maintain the YAML. And we can…

I work on a monorepo that does this using Typescript, for type checking. It's a mess. Huge learning curve for some type checking that very often will build perfectly fine but fail a type-check in CI.

Honestly, just having a linter should be enough. Ideally, anything complicated in your build should just be put into a script anyways - it minimizes the amount of lines in that massive YAML file and the potential for merge conflicts when making small changes.

Post reply on HN