What version of YAML is this intended to implement?

[DSGeoff]

I've been looking into this package a bit, looking through pull requests and issues. And, something that seems to be key to me is which version of YAML this is intended to implement. I haven't seen it mentioned anywhere. I am hoping this can be figured out, then made clear to anyone developing or using the package (e.g., in the README.md). Without knowing the version, on many aspects, developers won't know what to implement and users won't know how to use it. I've found specific issues where things can't move forward because no one seems to know the version.

Is this mentioned anywhere? If not, are there any hints or any people that can be asked? If not, can current developers get together in this thread and make a decision?

Examples of issues where knowing the version of YAML has specifically been mentioned as being necessary:
#18 , #122

There's also #41 (with an associated pull request), where the version isn't mentioned, but I think it's necessary. The poster is giving expected behavior by showing what PyYAML does. PyYAML implements version 1.1, which is somewhat outdated. I believe the octal representation changed in version 1.2.0, with the letter o now required, so the version matters. Here's an example from Version 1.1:

octal: 014

This example changes for Versions 1.2.0, 1.2.1, and 1.2.2:

octal: 0o14

[kescobo]

Yeah - good question. I think for simplicity, we should mostly try to implement the latest version of YAML, though where it's possible to support multiple versions, I think it would be kind to users for us to do so.

That said, this package hasn't seen much love in a number of years, and it wasn't written by me (my half-hearted stewardship is largely an accident), so your guess is as good as mine. The real answer to your question is, "whatever version that someone is willing to maintain," as unsatisfying as that is.

Let me make the implicit explicit here - do you want to take a crack at making it implement a particular version of YAML? 😉

[DSGeoff]

@kescobo , I'm no expert with YAML or with this package. I don't know enough about YAML to pick the version of YAML to implement. On one hand, it might make sense to use the latest version. On the other hand, I wonder if 1.1 is the most used due to PyYAML using 1.1 (and I think some C library it's based on using 1.1).

I did find that sexagesimal is no longer supported in 1.2, but the README says that still needs to be implemented. I'm not sure if that indicates the intent is 1.1 or just that whoever wrote that either didn't know which version was intended or didn't understand it's no longer supported in 1.2. But, that's another point where knowing the version is important.

There may be areas where supporting extra is helpful and possible. But, I think in a lot of areas, there's an expected way things will work and that expected way depends on the version. So, there's not necessarily a way to support extras without adding in some extra parameters or something. Here's an article I found with some key examples.

I do not want, nor do I have the expertise, to be in charge of implementing a specific version. I'm just trying to make it clear some group of people needs to decide on that. Could you tag various people who have tried to contribute to this lately, in this issue, and take a vote? Otherwise, I think it's difficult for this package to go anywhere because so many things depend on the version. Someone may do a pull request, and it may seem helpful. But, if it's specific to one version of YAML, it may not actually fit. If these are merged without an intended version, over time the package may become a jumble of different versions of YAML, which would make it difficult to use for anyone.

If I had a vote, based on my very limited knowledge, I probably would go with the latest version. It's a minor update from what existed when this package was started. And, I think the updates were made due to difficulties in prior versions. Whatever decision is made, once it's made, people can move that direction with this package. That would also allow someone else to create a different version if that was deemed important.

[DSGeoff]

Or, perhaps it makes sense to ask people who started this package rather than recent users. For example, say the group of recent users decides on the latest version of YAML. That will allow several issues to be handled quickly. At the same time, it may add a bunch of extra work if the package was actually designed for another version, because many things may need to be changed to go from the original intended version to the new intended version.

[kescobo]

The person who initially wrote this package is no longer active in the Julia. This decision ultimately needs to be made by the users / anyone who's willing to maintain it.

I'm just trying to make it clear some group of people needs to decide on that.

To be clear, I agree completely with your assessment, but alas I am also not a YAML expert 🤷

Recent contributors (where "recent" is "in the last 3 years") with largish additions include @mirkobunse @christopher-dG @programmeroftheeve @hexane360 @nlw0. I can also make a post on the #data channel in slack, and if you'd like to make a post on discourse to draw additional attention here, I think that might be worthwhile - there may be a lot of people with stake in YAML that aren't watching this Repo

[DSGeoff]

@kescobo I'm not sure what discourse is.

[kescobo]

🤦 right. I shouldn't assume that's common knowledge: https://discourse.julialang.org/c/domain/data/16

But also, @quinnj tentatively offered to take the reigns (on slack - there are more social channels here if you're interested).

[Paalon]

We should work to support YAML v1.2, then work to support v1.1. Leave the current behavior available. But it might need to deprecate them as a default. It is harmful.

[Paalon]

I want to support YAML v1.2 and deprecate the current behavior. I'll make a option to use the old (v0.4.10) behavior.

[Paalon]

There are many dependants of YAML.jl.
https://juliapackages.com/packages?dependee=yaml.
We will need to encourage users to use the Core schema as much as possible. If the Core schema lacks the necessary features (e.g. omap, timestamp, etc.), we must inform them to transition to a different schema.

[kescobo]

To that end, I wonder if we should add some downstream tests for some of the major dependents before embarking on a series of breaking changes. That would at least flag for us which things are going to cause widespread breakages and provide an imperative to notify.

Is there a way on juliahub to see just direct dependents? A bunch of packages in that list seem to be indirect.