There is snakeyaml-engine 2.x - (new snakeyaml version)

[ieugen]

Hi,

To whom it may concern, there is snakeyaml-engine - which is the new/refactored version of the library https://bitbucket.org/asomov/snakeyaml-engine/src/master/ .

There are some changes here and a wiki with documentation https://bitbucket.org/asomov/snakeyaml-engine/wiki/Changes .

Load api for yaml in version 2.3 https://javadoc.io/doc/org.snakeyaml/snakeyaml-engine/latest/org/snakeyaml/engine/v2/api/Load.html

Regards,

[marcomorain]

Hi @ieugen, are you suggesting that we change clj-yaml to build on top of SnakeYAML 2.x?

Are there any user-visible benefits from that upgrade?

FWIW, in recent projects at CircleCI, I've taken to using SnakeYAML directly, rather than clj-yaml. I don't expect the folks at CircleCI to put in any major investment in this library at present.

[The-Alchemist]

If I may chime in, as an outsider:

• the latest snakeyaml-engine release was 2.3 (2021-04-19)
  • it's still active (https://bitbucket.org/snakeyaml/snakeyaml-engine/commits/), though
• the "original" library (https://bitbucket.org/snakeyaml/snakeyaml/commits/) is still in active development as well.
  • latest version of the original library is 1.30 (2021-12-14)

So I'm not exactly sure which is the "new" library, and what the difference between the APIs is, and what improvements to switching.

There is a Google Group (https://groups.google.com/g/snakeyaml-core), is someone is interested in venturing deeper.

Cheers

[wongjoel]

As far as I understand, the biggest difference is that snakeyaml supports YAML 1.1, whereas snakeyaml-engine supports YAML 1.2.

My usecases of YAML all involve very simple YAML files, so I can't bring to mind a clojure use-case where this would matter.

[The-Alchemist]

As far as I understand, the biggest difference is that snakeyaml supports YAML 1.1, whereas snakeyaml-engine supports YAML 1.2.

Thank you, @wongjoel . I agree that this is the biggest difference between snakeyaml and snakeyaml-engine. Looks like YAML 1.2 is designed to move it closer to a superset of JSON (i.e., explicitly support JSON).

There's also some internal changes to make smaller modules it looks like. Some references:

• https://en.wikipedia.org/wiki/YAML#Comparison_with_JSON
• https://groups.google.com/g/snakeyaml-core/c/L0Tf21ONvaI

Migration to snakeyaml-engine would be a nice addition, but probably a low priority. We can throw the YAML 1.2 files from the spec at the unit tests and see what happens. If I have the time, I'll take a stab at it. ;)

[borkdude]

Doesn't snakeyaml use snakeyaml-engine internally?

[The-Alchemist]

Doesn't snakeyaml use snakeyaml-engine internally?

I don't think so.

• Separate web pages
  • https://bitbucket.org/snakeyaml/snakeyaml/src/master/

SnakeYAML is a YAML 1.1 processor for the Java Virtual Machine version 7. For YAML 1.2 (which is a superset of JSON) you may have a look at SnakeYAML Engine

• https://bitbucket.org/asomov/snakeyaml-engine/wiki/Home
• separate releases in Maven Central

[borkdude]

Trying snakeyaml engine as the "backend" of this lib would likely solve #35

[borkdude]

As this is not an issue, but more something to be aware of, I converted this to a discussion. Issues are going to be used for things that are ready to be worked on.

[ieugen]

Doing some more reading since looking into using yaml as a configuration language.
There are some issues with yaml https://www.arp242.net/yaml-config.html

I think version 1.2 makes things more strict and resolves some of the issues that might surprise you when parsing yaml.
See https://perlpunk.github.io/slides.tpcig2018/yamlpp/slide022.html - has examples about truth values.
In yaml 1.1 'Yes' is boolean true :) .

Since I am planning to parse yaml configuration and use it as code I would like to be as strict as possible.
Also conversion to and from json is a nice to have (which is one of the goals of yaml 1.2 spec)

https://yaml.org/spec/1.2.0/

The primary objective of this revision is to bring YAML into compliance with JSON as an official subset. YAML 1.2 is compatible with 1.1 for most practical applications - this is a minor revision. An expected source of incompatibility with prior versions of YAML, especially the syck implementation, is the change in implicit typing rules. We have removed unique implicit typing rules and have updated these rules to align them with JSON's productions. In this version of YAML, boolean values may be serialized as “true” or “false”; the empty scalar as “null”. Unquoted numeric values are a superset of JSON's numeric production. Other changes in the specification were the removal of the Unicode line breaks and production bug fixes. We also define 3 built-in implicit typing rule sets: untyped, strict JSON, and a more flexible YAML rule set that extends JSON typing.

In my opinion, yaml 1.2 is a safer choice - since it was simplified.
For my use case I would use the strict JSON rule set.