I am investigating how to make generated YAML more idiomatic

Question

I am investigating how to make generated YAML more idiomatic per standard Github Actions conventions could there be a future where `snakeyaml engine` is replaced by a dedicated YAML builder in the `library` module in pursuit of this happy to fully prototype and test a replacement for the snakeyaml emitter

Damien O&apos;Hara · Answer

I know that YAML is complex and so a third party dependency seems like a foregone conclusion but I note that 1 the needs of the `library` module are restricted to serializing model objects to a subset of YAML this is a simpler case than full YAML representation or parsing 2 `snakeyaml engine` isn t successfully shielding the library from much complexity by deferring e g quote rules to caller 3 serialization is already handled in house with ` toYamlInternal`

Vampire · Answer

There was a built in serialization before that caused many unnecessary problems So it was recently replaced by a proper YAML implementation I doubt it will be changed back

Vampire · Answer

Also what do you think is non idiomatic

Damien O&apos;Hara · Answer

I did have a look at the pre snakeyaml serialization before I asked + the associated PR and issues I don t think it is fair to attribute the issues with the old implementation to built in serialization in general the old implementation was ad hoc and relied heavily on string interpolation taking a more structured approach to generation won t have the same issues

Damien O&apos;Hara · Answer

I found quite few style differences porting handwritten YAML to generated some of them are unrelated to serialization step ids some of them exist between serialization and emission e g emitting `field ` instead of implicit `field ` and some of them are at the emission layer only ` ` isn t indented in output the last one I could not find any way to fix in snakeyaml but it s possible I ve overlooked a configuration value somewhere

Piotr Krzemiński · Answer

Is it only about YAML style If yes I wouldn t like to change anything here at least now The serialization problem has already consumed too much time and given my limited bandwidth for the project I d prefer us to focus on more crucial things Even if you contribute a tailor made solution it will add a piece of complexity that will have to be maintained primarily by me and it creates a risk of regressions I also don t want the YAML to be particularly pretty snakeyaml engine is not perfect but does the job

Piotr Krzemiński · Answer

The primary problem with the lib now is insufficient feature coverage I d gladly accept some help here if you d like to contribute

Damien O&apos;Hara · Answer

understood no need to create work that can t be prioritized