Repository navigation
yaml-rust appears unmaintained... #1921
Description
See also chyh1990/yaml-rust#197
Reacted by ratijas, Bent Hillerkus, Lukas Valatka, Towry Wang and Maurycy Pawłowski-Wieroński
Reacted by John Vandenberg, Suraj, Rich Seymour, Ame アメ and Javier Dehesa
Activity
qtfkwk commentedon Mar 13, 2024
Stumbled onto https://crates.io/crates/yaml-rust2 / https://github.com/Ethiraric/yaml-rust2 yesterday... it forks from the latest commit on the original repository https://github.com/chyh1990/yaml-rust on 2021-07-12, and adds commits starting on 2023-08-14 and latest on 2024-02-08.
I've done a quick review and appears to be functional and in good faith, but should have more people review and confirm.
Also, strangely... @Ethiraric doesn't seem to have any means of contact posted in Github, and has issues disabled on the yaml-rust2 repository (?).Edit: resolved... see #1921 (comment)Ethiraric commentedon Mar 13, 2024
Heya!
Having issues disabled was (I think) an unintended side-effect of the repository being a fork in a first place and was not at all intentional.
It forks from one of the pull requests from the original
yaml-rustwhere the author added support for the yaml test suite, a set of YAML files and their expected output.yaml-rustdid not pass the whole test suite. Although most of the tests were corner cases that were unlikely to be encountered in real-world YAML, I have fixed all of them so thatyaml-rust2now correctly passes the whole suite.I've also added a bunch of comments to the code, refactored some constructs and optimized so that the library should be faster than
yaml-rust.I have waited to produce real benchmark data before doing an announced release. I am fairly new to the art of benchmarking, and my last attempts at optimizing have failed, which is why there hasn't been any meaningful commit for a month now.
As-is, I see no reason the code would be less functional than
yaml-rust, but I am human and make errors, so maybe there's something I missed, in which case a bug report (now that I have issues enabled, thanks to you) would be welcome.If there's anything I could help with, do feel free to open an issue or send me an e-mail (I'll add that to my profile in a second, but I have a gmail address whose local part is my username here).
smoelius commentedon Mar 13, 2024
@davvid's https://crates.io/crates/yaml-rust-davvid is another fork that, to the best of my knowledge, is sincere.
davvid commentedon Mar 14, 2024
Yes, I'm relying on the availability of this functionality long-term so I'd be more than happy to help maintain a fork or swap over to a different fork. I wasn't aware of yaml-rust2, thanks for bringing that to my attention.
Ethiraric commentedon Mar 14, 2024
I've had a look at the commits on @davvid's repository, and it seems that they are mostly focused on the output API and handling of
Yamlelements. If that's the case, our works should be complementary as I almost exclusively focused on the parsing side of the project.Ethiraric commentedon Mar 15, 2024
@davvid Our repositories should have a common ancestor in the latest
yaml-rustcommit.Would it be okay with you if I tried merging your commit tree into my repository?
davvid commentedon Mar 17, 2024
@Ethiraric that'd be great. I actually started on the merge before seeing your message and submitted the changes in a clean rebase over at Ethiraric/yaml-rust2#2
Ethiraric commentedon Mar 18, 2024
Thank you very much for your work on this pull request! I hope we can get it to merge cleanly soon ❤️
tarcieri commentedon Mar 18, 2024
I just wanted to say that
yaml-rustappears to be implicitly unmaintained, however per our unmaintained crates policy we prefer to wait for 90 days after an issue like chyh1990/yaml-rust#197 has been opened to give the author time to respond.If someone would like to file an unmaintained crate advisory in advance, we can merge it when that time has elapsed.
davvid commentedon Mar 20, 2024
I'm linking these here so that folks landing here can see the full paper trail going back to 2020. I guess waiting another 3 months isn't really going to hurt (or change much) in that respect since we've already waited ~4 years.
chyh1990/yaml-rust#160
chyh1990/yaml-rust#192
tarcieri commentedon Mar 20, 2024
Aah, with chyh1990/yaml-rust#160 especially it seems clear this crate is unmaintained as the maintenance status has already been publicly asked about without response.
Feel free to file an advisory then. It can be merged immediately.
Add an unmaintained crate advisory for yaml-rust (#1922)
jayvdb commentedon Mar 25, 2024
Using the latest https://crates.io/crates/yaml-rust2 results in https://osv.dev/RUSTSEC-2021-0153
tarcieri commentedon Mar 25, 2024
@jayvdb that would be good to report on the
yaml-rust2repo: https://github.com/Ethiraric/yaml-rust2/issues3 remaining items
rocallahan commentedon Mar 26, 2024
Right. Is there no procedure at all to take over the crate name of a core crate that has been completely abandoned? That seems bad.
tarcieri commentedon Mar 26, 2024
No, there is not. The only way to deal with a non-communicative author is a fork.
rocallahan commentedon Mar 26, 2024
That is a very bad policy. Bad to the point of ridiculous in a situation like this.
jayvdb commentedon Mar 26, 2024
@rocallahan , it is a known problem being discussed elsewhere; it is the way it is because of security, so will require a very careful process to override the current security. rust-lang/crates.io#7202 is one semi-related discussion.
Maybe some useful discussions at https://users.rust-lang.org/search?q=unmaintained ?
e.g. https://users.rust-lang.org/t/pre-rfc-we-need-a-process-for-giving-crates-to-new-maintainers/8033 which leads to rust-lang/rfcs#1794
jayvdb commentedon Mar 26, 2024
Ethiraric/yaml-rust2#16 will resolve this.
rocallahan commentedon Mar 26, 2024
Thanks for the pointers but I don't see any active discussion that covers this specific situation.
rocallahan commentedon Mar 26, 2024
I see on crates.io yaml-rust is listed as having two owners, and one of them is
dtolnay-contrib/yaml-rust. So could dtolnay reassign the yaml-rust crate name to the yaml-rust2 contributors?tarcieri commentedon Mar 26, 2024
@rocallahan you would have to ask @dtolnay
Turbo87 commentedon Mar 26, 2024
FWIW the Python ecosystem has https://peps.python.org/pep-0541/ but when we updated the crates.io policies last year there was a lot of opposition against including something like this.
Ethiraric commentedon Mar 26, 2024
This has already been asked. Crates.io has already been informed of the issue.
Prior to starting
yaml-rust2, I have already asked around for any other way this could be resolved. A lot of options have been explored and I do not think any more discussion about possible ways to take overyaml-rusthere will come to fruition.qtfkwk commentedon Mar 27, 2024
A "takeover" causes more problems than it's worth. And that's even if it's 100% compatible.
You have competing issues... on one hand you might be thinking: we gotta force everyone who depends on an old and unmaintained crate to upgrade for security reasons. Well (a) you can't because they might have chosen to depend on a specific old version, (b) if they didn't you might be introducing breakage, and (c) it's their problem if they depend on old and unmaintained crates... they still need to exist so the whole thing doesn't fail.
Further, afaik cargo-audit is an aid to help inform authors and users about security issues... not enforce anyone's particular requirements.
IMHO, the best way is as it is: Make a new crate, fork, whatever. Let crate authors depend on whichever crates/versions they want. Done.
[core, tui] Fix doc links errors, update Cargo.lock, update CHANGELOG.md
[core, tui] Fix doc links errors, update Cargo.lock, update CHANGELOG.md
index: replace unmaintained yaml-rust crate with the up to date yaml-…
[core, tui] Fix doc links errors, update Cargo.lock, update CHANGELOG.md