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

151–159 of 159 posts

Re: Dear GitHub: no YAML anchors, please

#151

Post by floydnoel »

iLoveOncall wrote: post #99
jayd16 wrote: post #60

Earlier quoted context omitted.

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.

i might be autistic, but i freakin loved CloudFormation templates. i replaced all the ad-hoc infrastructure in my company with it in less than a year, giving me the ability to spin up production-identical staging environments at-will! never really liked the CDK tho. dunno why

Re: Dear GitHub: no YAML anchors, please

#152

Post by doublet00th »

0xbadcafebee wrote: post #129
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.

A custom language in GHA would be worse. You'd be limited by whatever language they supported, and any problems with it would have to go through their support team. It adds more burden on GHA (they spending more time/money on support) without creating value (new features you want). You already don't have to use YAML. Use whatever language you want to define the configuration, and then dump it as YAML. By using your o…

This is what we built at my last startup Pangea (except with GitLab CI/CD). It worked pretty well and I always wanted to open-source it, but alas in a startup there's never enough time.

Re: Dear GitHub: no YAML anchors, please

#153

Post by btreecat »

woodruffw wrote: post #67
btreecat wrote: post #65

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 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?

> > 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?

When you say something comes down to engineering "taste" then you've already reduced your own argument.

Re: Dear GitHub: no YAML anchors, please

#154

Post by rurban »

ericHosick wrote: post #49
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.

Yes! Hopefully a language that supports code as data (homoiconicity).

There is yamlscript for you now :) No security of course.

Jokes aside, I like proper yaml anchors. Other CI's do support these and it made writing yaml actions much easier, esp. complicated cross-building recipes with containers and qemu.

Re: Dear GitHub: no YAML anchors, please

#155

Post by soraminazuki »

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.

A JSON-like language with functions is the answer here. When it comes to describing large, complex, and sometimes repetitive data, having a declarative language with proper tools for abstraction helps so much with readability, writability, and maintainability.

I've seen few thousands-line YAML files with anchors riddled all over the place. It was impossible to deal with. Rewriting it in Jsonnet paid off immediately.

Another example is Nixpkgs. It's quite pleasant to deal with despite the size of its codebase.

Re: Dear GitHub: no YAML anchors, please

#157

Post by woodruffw »

btreecat wrote: post #153
woodruffw wrote: post #67

Earlier quoted context omitted.

> 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?

> > 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? When you say something comes down to engineering "taste" then you've already reduced your own argument.

I don't know whether this intentional or not, but you seem to be omitting the context where "taste" comes into play: it's not about which things are better or not, but about exercising discretion in how much variety to expose in a large system.

If it makes things easier for you, you can substitute between these two.

Re: Dear GitHub: no YAML anchors, please

#158

Post by Levitating »

tarkaTheRotter wrote: post #120
Levitating wrote: post #96

Earlier quoted context omitted.

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

Hey - maintainer here. Sorry about your bad experience and thanks for mentioning it! The Core Web Vitals test did come back ok - but evidently there's more to do so will get that sorted. (Web design not a strong point! ). The code examples should be showing on smaller screens when in landscape on mobile (they looked awful in portrait) - but will also look at that as well! Could I possibly ask you to reply with the mo…

Hey! I must've responded to the wrong thread. Unless the link on this post was changed.

You're blog looks just perfect to me, and loads fine even on my extremely slow Redmi A5. And even the code examples look fine.

So sorry! I must've accidentally written my comment on the wrong page.

The post I thought I was responding to showed a website with an animated "breathing" background which was completely locking up my phone.

Edit: Just to drive this point home, if you're the author https://blog.yossarian.net you've made a perfect looking blog and I wouldn't change a thing.

Re: Dear GitHub: no YAML anchors, please

#159

Post by louiskottmann »

Gitlab has had that for a while, and it's very useful as in-between through dot targets.

i.e:

.scoped-env: &scoped-env

   key1: value1

   ...
Dot targets are ignored semantically, only inheritors make them useful.

Then further down you can reuse *scoped-env wherever you need.

You can also have anchors on individual lines and compose them. It's useful.

The author suggests using ad-hoc syntax, or meta-keys. Gitlab supports that [1] and I use them as well.

Different but also combinable uses, for various people. Nothing wrong with it.

1: https://docs.gitlab.com/ci/yaml/#extends

Post reply on HN