Crate deletion allowances

[clarfonthey]

This RFC proposes adding a number of "reasonable changes" to the current crates.io deletion policy that will allow the deletion of several "reasonable to delete" crates which currently do not qualify.

They are definitely, directly, shamelessly motivated by the personal experience of the RFC author. Please let them know if anything was poorly or hastily worded.

Important

When responding to RFCs, try to use inline review comments (it is possible to leave an inline review comment for the entire file at the top) instead of direct comments for normal comments and keep normal comments for procedural matters like starting FCPs.

This keeps the discussion more organized.

Rendered

[Diggsey]

With the proposed changes it becomes important to specify whether this is a direct or a transitive dependency.

(eg. consider [regular crate] -> [yanked crate] -> [crate to be deleted])

[clarfonthey]

I decided to just elaborate this section more fully to make it clearer; what do you think now?

[joshtriplett]

Suggested change

	* Yanked versions which are over a year old are not considered as valid reverse dependencies. If the depended crate passes the deletion criteria and gets deleted, these yanked versions may also get deleted.
	* Yanked versions which are over a year old might not considered as valid reverse dependencies. This evaluation may take into account whether the dependency appears to be accidental/unused.

We should not be deleting old yanked versions of established crates; unless there's some malice involved, they should stick around for archival purposes. Also, consider that a crate might have a feature-flagged dependency using a feature that isn't intended for most people to use. I realize that "may also get deleted" is broad and subject to discretion, but I don't think we should leave that possibility open.

We could, potentially, say something like "If the depended crate passes the deletion criteria and gets deleted, that would be taken into account for any subsequent evaluation of the depending crate or its yanked versions."

[clarfonthey]

The thought process here is to consider the case where only yanked versions contain the dependency: even just one non-yanked version having the dependency overrides this requirement and means that both versions remain.

That said, you're right that deleting the versions is probably excessive; we already have crates that might not compile on crates.io and that's fine, so, there's no harm in keeping yanked versions up. (I will edit that probably later today.)

[clarfonthey]

(Have since updated the text to remove that bit.)

[joshtriplett]

As written, this criteria is much too broad. For instance, it's legitimate for a crate to only work on nightly, not on stable.

It seems like this is written in order to enable the previous requirement. But we shouldn't be force-yanking a crate version. We might, potentially want to ignore it for the purposes of evaluating the deletion criteria.

Suggested change

	* If a version of a crate has been failing to compile on the latest stable for over 4 years (~1 edition cycle), it may be yanked without the approval of the crate author. Since these versions are necessarily at least four years old, they also satisfy the requirements for the above criteria.
	* If a version of a crate has been failing to compile on the latest stable for over 4 years (more than a full edition cycle), it may be ignored for the purposes of evaluating reverse dependencies. This evaluation may take into account whether the dependency appears accidental/unused.

[clarfonthey]

The idea behind yanking is that ultimately, the version does not compile, and so it's definitely doing something weird and obscure that probably doesn't apply any more. Given Rust's strong stability guarantees, this usually only happens for inference changes that have known-minimal breakages (meaning this was already evaluated to be within those known, minimal breakages) or explicit soundness issues, which again, would have already been evaluated.

And, we also can still keep yanked versions around, just, they've been signalled to not be recommended.

[oskgo]

I think yanking versions that are broken on the default toolchain (latest stable) goes beyond what yanking has traditionally been for. There are legitimate reasons for a crate version to have a different toolchain in mind, such as latest nightly or fixed version/nightly.

Maybe it's relying on a feature that's on the path to stabilisation. This is the case with the Rust for Linux kernel crate for example, though that one isn't published to crates.io. Old versions with #![feature(...)] are going to fail to compile on stable, even when those features have been stabilised.

There are also crates that pin themselves to a certain version/nightly that's moved intermittently, usually because they rely on implementation details. The pinned version won't be the latest. I think this used to be (is?) the case for some crates in the formal verification ecosystem, but I don't recall the details. Force yanking old versions here might make it more difficult to verify old artifacts for projects that don't put Cargo.lock in version control.

[clarfonthey]

You are right and I guess that we would have to pave a path specifically for allowing the current nightly if it turns out that a feature genuinely exists in the compiler for a full edition cycle, since it would still compile. I'll think a bit on how to word that.

[joshtriplett]

(These would need updating per the suggestions above.)

[fintelia]

What happens if the crate author tries to un-yank the version? Are they blocked from doing so?

[clarfonthey]

I had no idea that unyanking was even supported by Cargo, but yeah, I guess that cargo yank --undo exists, now that I'm looking at it.

I actually have no idea about the specifics of this, and whether it's time-gated or not, but it appears that this is a valid action, so, will have to look more into it.