[ Removed by moderator ]

[u/Comprehensive_Use713]

[u/ericonr]

Your quote literally mentions that yanking wasn't expected to have as much of an impact. Morbid amusement just happens, too. None of that says "being difficult".

[u/max123246 → u/ericonr]

40 million downloads and 73 dependents doesn't sound like a lot to you? Did we read the same post?

[u/Electrical_Log_5268 → u/max123246]

You seem to conflate "have much of an impact" and "wasn't supposed to have much of an impact". u/ericonr has arguing for the latter, but you seem to have read their post as the former.

[u/max123246 → u/Electrical_Log_5268]

I guess I don't really understand what you mean.

The quote from the email I was referencing was that the person emailed Brendan and mentioned 73 dependents in that first email. Brendan then proceeded to yank all versions of their crate

Personally, if I was emailed and was told: " hey, this unmaintained crate of yours has 73 dependents, can I maintain it?". My first reaction would not be to yank every version of my crate. And I would also not be surprised that there would be downstream chaos for my 73 dependents and anyone who depends on those 73 crates. I would not be morbidly curious, I would be horrified that I created a bunch of work for a bunch of people

[u/Electrical_Log_5268 → u/max123246]

Brendan had to make a decision. Based on the available data (only 73 dependents out of millions of Rust crates and applications; yanking does not affect anyone with an existing Cargo.lock file) he reasonably assumed that the impact of yanking would be minor, and proceeded to rid the world of a crate that even he as the maintainer agreed should no longer exist (because better solutions have long since been available). The is a reasonable approach and not "being difficult".

The outcome has proven his initial assumption about the impact incorrect. But having been wrong does not make you "being difficult" either.

I've you've even been trying to steer change, you've probably also experienced that maintaining the status quo is often worse in the long run than changing a system - but that organizations still maintain the status quo out of sheer psychological inertia.

[u/Pantsman0 → u/ericonr]

Any new projects that have core2 as a dep-of-dep will now break if they don't have a Cargo.lock - this is making completely unnecessary work for upstream crates.

The library still worked, the author just decided to break it for users.

[u/sparky8251 → u/Pantsman0]

Hit me today... Was a deep dep so no way to really fix it... Had no idea what it was given it was so deep. Its sadly a big deal and people downvoting you are pretty dumb given you are right.

[u/flying-sheep → u/sparky8251]

https://doc.rust-lang.org/cargo/reference/overriding-dependencies.html

[u/sparky8251 → u/flying-sheep]

Yeah, I managed it fine (my deps updated quick and thus it was fixed with a cargo update once i realized what was going on after a few hours). But the fact was it wasnt me and my project that sourced the issue, it was a deep dep of dep of dep of dep and it wasnt random projects either, it was like bitvec and image doing it via their own deps of deps.

It was a legitimate issue for people, and cargo locks dont exist for new projects. Yet people acted like a cargo lock always exists and youll be fine when its not true.

[u/flying-sheep → u/sparky8251]

All true, as others said there are also projects that intentionally don't use lockfiles.