New package: LibYAML2 v0.1.0

[JuliaRegistrator]

• Registering package: LibYAML2
• Repository: https://github.com/bhftbootcamp/LibYAML2.jl
• Created by: @gryumov
• Version: v0.1.0
• Commit: 83ded8f48476c6bbd78a6c8be7c78108d77d306e
• Reviewed by: @gryumov
• Reference: bhftbootcamp/LibYAML2.jl@83ded8f#commitcomment-160259584
• Description: A Julia wrapper for libyaml, providing fast and minimal YAML parsing

[github-actions]

Hello, I am an automated registration bot. I help manage the registration process by checking your registration against a set of AutoMerge guidelines. If all these guidelines are met, this pull request will be merged automatically, completing your registration. It is strongly recommended to follow the guidelines, since otherwise the pull request needs to be manually reviewed and merged by a human.

1. New package registration

Please make sure that you have read the package naming guidelines.

2. AutoMerge Guidelines which are not met ❌

• Package name similar to 1 existing package.
  1. Similar to LibYAML. Damerau-Levenshtein distance 1 is at or below cutoff of 2. Damerau-Levenshtein distance 1 between lowercased names is at or below cutoff of 1.

3. Needs action: here's what to do next

1. Please try to update your package to conform to these guidelines. The General registry's README has an FAQ that can help figure out how to do so.
2. After you have fixed the AutoMerge issues, simply retrigger Registrator, the same way you did in the initial registration. This will automatically update this pull request. You do not need to change the version number in your Project.toml file (unless the AutoMerge issue is that you skipped a version number).

If you need help fixing the AutoMerge issues, or want your pull request to be manually merged instead, please post a comment explaining what you need help with or why you would like this pull request to be manually merged. Then, send a message to the #pkg-registration channel in the public Julia Slack for better visibility.

4. To pause or stop registration

If you want to prevent this pull request from being auto-merged, simply leave a comment. If you want to post a comment without blocking auto-merging, you must include the text [noblock] in your comment.

Tip: You can edit blocking comments to add [noblock] in order to unblock auto-merging.

[goerz]

For anyone reviewing, #133076 (comment) and following still applies.

Personally, I would probably be happiest with this being a submodule of Serde.jl

[kellertuer]

What I do not like is, that the package does not even mention LibYAML; for best of cases the currently abandoned package should be reactivated to avoid confusion (in the case of this happening more often: something like: Which of the LibYAML1-17 is the one that is still maintained?)

I think making this a submodule within Serde would probably best.

[gryumov]

What I do not like is, that the package does not even mention LibYAML

Agreed, we should add a mention of LibYAML to clarify the relationship

[kellertuer]

Note that LibYAML also has been moved by now and is at https://github.com/JuliaData/LibYAML.jl and hence probably no longer abandoned.

[goerz]

Despite my misgivings in #133076 (comment), I agree with @ChrisRackauckas in #133076 (comment) that this should replace the existing LibYAML. The idea of the General registry is very much that of a shared community resource, which comes with the recommendation for very general and descriptive package names (which then should be the "canonical" package for its domain), and the idea that when packages become unmaintained, they can be transferred to one of the established Julia organizations and assigned a new maintainer. For LibYAML that is exactly what happened: LibYAML was transferred to JuliaData so that the it can be assigned a new maintainer, in this case potentially @gryumov or @kbarsegian, who can then integrate the code from https://github.com/bhftbootcamp/LibYAML2.jl and release it as a new breaking version.

Unfortunately, based on the communication here and in the earlier threads surrounding this new LibYAML version, as well as similar experiences with half a dozen previous registrations, I'm not sure that there is an alignment between this community-managed aspect of packages in the General registry and the way BHFT Bootcamp handles the development of Julia packages. That is completely fine, and why the guidelines for General recommend a local registry for "packages that are only useful for a closed group (like a research group or a company)". Hence my recommendation, or personal preference, for BHFT Bootcamp to keep their entire ecosystem in the dedicated registry at https://github.com/bhftbootcamp/Green. However, the fact is that Serde.jl (and some other BHFT Bootcamp packages) are in General, which means that if Serde wants to use this new LibYAML implementation (which it is absolutely entitled to do), that leaves two options:

• Work within the community to maintain the new code as part of the existing LibYAML, within the JuliaData organization
• Add the new LibYAML implementation as a submodule to Serde

I don't think the community interests are really compatible with having a separate LibYAML2 when the original LibYAML can still continue. But I'm also okay with others (the registry maintainers) taking a different view on this, and merging LibYAML2.

[gryumov]

@goerz, Are you willing to make me a maintainer of LibYAML under JuliaData?

[goerz]

I have no such permissions, this is up to whoever has admin access to that org, like probably @DilumAluthge

[stepanplaunov]

I don't think leaving LibYAML in Serde as a submodule is the right decision. Serialization in Serde.jl is built on the use of separate libraries designed for specific data types. LibYAML is just one of them and inlining such a library in Serde will break the abstraction of the package.

From what I can see, the current LibYAML implementation is essentially empty, so starting with the implementation from this PR seems optimal.

[kellertuer]

If there is a push towards revitalising LibYAML, sure that should not live within Serde, you are right. But with the original package now moved to JuliaData, that might happen and the developers here should probably join that.

My main incentive to have LibYAML2 within Serde is, that we should avoid having too many similar named packages doing the same thing in General.
I like that usually I can nearly guess names and it works – I do not have to remember wether I have to use some PkgName or PkgName2 for it to work.

So I still would propose to join forces with who ever is maybe left on the original LibYAML and do an (hopefully even better) package together.

[kellertuer]

Are you willing to make me a maintainer of LibYAML under JuliaData?

Even without being a maintainer, you can open issues and do PRs, since it is now in JuliaData there are hopefully a few developers keeping an eye on those.