3 ms·

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?

woodruffw 1y ago
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.)
- btreecat 1y ago
  > 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"
  - woodruffw 1y ago
    > 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?
    - btreecat 1y ago
      > > 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.
      - woodruffw 1y ago
        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.
- VGHN7XDuOXPAzol 1y ago
  > 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 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
  - woodruffw 1y ago
    > Call it github-flavored YAML (GFY) or something and accept a different file extension. Sure, I wouldn't be upset if they did this. To be clear: there aren't many fully conforming YAML 1.1 and 1.2 parsers out there: virtually all YAML parsers accept some subset of one or the other (sometimes a subset of both), and virtually all of them emit the JSON object model instead of the internal YAML one.
deleted 1y ago
[deleted]

woodruffw 1y ago

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.)

btreecat 1y ago
> 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"
- woodruffw 1y ago
  > 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?
  - btreecat 1y ago
    > > 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.
    - woodruffw 1y ago
      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.
VGHN7XDuOXPAzol 1y ago
> 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 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
- woodruffw 1y ago
  > Call it github-flavored YAML (GFY) or something and accept a different file extension. Sure, I wouldn't be upset if they did this. To be clear: there aren't many fully conforming YAML 1.1 and 1.2 parsers out there: virtually all YAML parsers accept some subset of one or the other (sometimes a subset of both), and virtually all of them emit the JSON object model instead of the internal YAML one.

deleted 1y ago

[deleted]