Suggestion: cargo yank is a misfeature and should be deprecated and eventually removed

tools and infrastructure cargo
41

Maybe we could introduce a finer mechanism so the owner of a crate can mark some versions as Vulnerable, Broken_API, Major_issue, Unmaintained, ... with an issue id (like a rustsec id) and a comment. A warning would be raised if a marked crate is used. I'd advocate that crates with vulnerabilities and broken api might still be treated as currently yanked crates. You would still be able to ignore an issue with a parameter like ignore="RUSTSEC-2023-0666"

But right now, yanking is the only mechanism available to reach the users than does not use external tools when there is a problem. If we want to deprecate yanking, we need to introduce a better feature as replacement first.

5 Likes
42

It doesn't make sense to put "ignore yanking" options in Cargo.toml. The point is that you don't know which crates should ignore yanking until they're yanked, and you need it most on legacy and historic code anyway, where you can't change the Cargo.toml.

It should be a flag on cargo call itself. Perhaps writing a special cargo tool to ignore yanking is the best solution. It doesn't look like we'll get any compassion around here.

4 Likes
43

I think you have an opportunity to focus your argument here better.

Thank you for this comment --

I want to try to give a more concrete example, or series of examples, where I think that yanking can cause cargo to do something undesirable and where the amount of stuff I have to do to get it not to do that grows larger and larger.

I haven't had time to put together such an example in detail, but I think I will have time later this week. Thanks to everyone who has commented for their interest in this issue.

3 Likes
44

Giving an overridable error on an attempt to yank the final available version of a semver bracket is a good idea, I think. Something like this:

error: attempt to yank the final remaining version of 0.13
help: publish a new 0.13.7 version first, or run with --ignore-semver

And similarly for a gross publishing error, which is what I would argue yank is intended for:

error: attempt to yank the final remaining version of 999999

"ignore semver" is clearly a sensible response to being told people won't be able to use version 999999 anymore.

3 Likes
45

A patch for this is trivial btw, I've made one years ago. The tough part is convincing the cargo team to accept it. And yes, this can 100% be an external tool... maybe I should make one.

3 Likes
46

(This is the epitome of bikeshedding the naming of a small part of something where the whole design is in question, but IMO it should be --allow-yanked since "ignoring yanked crates during version resolution" is the default (and for that reasoning I used it in cargo-dl)).

3 Likes