Unhelpful Cargo error if crate version disappears from registry

[jonhoo]

Problem

If the version listed in Cargo.lock for a dependency is no longer available from the registry, Cargo fails the build with an error even if --locked is not passed. The error does not suggest what has happened, or what the user might want to do in response.

There are a few reasons why this might happen. For crates.io, the most likely reason is if a crate version must forcibly be removed from a registry, such as due to a DMCA notice, a GDPR "Right to be Forgotten" request, a government injunction, or other factors beyond Cargo and crates.io's control.

For private registries, additional cases may arise, such as if local registries are built on the fly when Cargo is managed by a larger build system, and a version that was published on one developer's laptop (say, while they were offline) never makes it to other developers, but a lockfile mentioning that version is nevertheless checked in.

Steps

1. cargo new vanish
2. cd vanish
3. `echo 'autocfg="1"' >> Cargo.toml
4. cargo check
5. sed -i.bkp 's/1\.0\.1/1.0.100/' Cargo.lock
6. cargo check:

    Updating crates.io index
error: failed to select a version for the requirement `autocfg = "=1.0.100"`
candidate versions found which didn't match: 1.0.1, 1.0.0, 0.1.7, ...
location searched: crates.io index
required by package `vanish v0.1.0 (~/vanish)`

Possible Solution(s)

This was discussed at some length on Zulip. The challenge here is that if a user runs into this, it's not clear from the error what happened, or what they should do next. The Zulip discussion surfaced two possible solutions:

1. Have Cargo issue a warning rather than an error, and instead pick whichever version it would pick if the given version were not mentioned in Cargo.lock. @Eh2406 suggested this may be a fair amount of work, and @joshtriplett argued that this situation warrants manual user action (cargo update) to proceed. Cargo continuing to use yanked versions when mentioned in the lockfile also suggests a precedent that Cargo shouldn't move on from the version in Cargo.lock without user intervention.
2. Make the Cargo error more descriptive, including what went wrong, and what the user can do to remedy the situation. One could, for example, imagine crates.io leaving tombstones for redacted versions with redaction messages that Cargo could print, or in the absence of those, Cargo could at least say that the version in the lockfile disappeared from the registry and suggest the user run cargo update (or even specifically cargo update -p <package>).

Option 2 definitely seems like the most promising candidate here, though it does make the second use-case outlined earlier (on-the-fly local registries) more painful as developers may regularly have to run cargo update (or the build system would need to do so for them somehow) if they check in their lockfiles. The behavior could arguably be made configurable, but if Option 1 turns out to be complex to implement, that may not be feasible.

Notes

No response

Version

cargo 1.56.0 (4ed5d137b 2021-10-04)
release: 1.56.0
commit-hash: 4ed5d137baff5eccf1bae5a7b2ae4b57efad4a7d
commit-date: 2021-10-04

[jonhoo]

The plot thickens. If I have

[patch.crates-io]
autocfg = { path = "autocfg" }

where autocfg/Cargo.toml still gives version = "1.0.1", then cargo check succeeds even if I modify Cargo.lock to specify version 1.0.100, so the version gets automatically downgraded.

And it gets better. If I then remove the [patch] (but again make Cargo.lock have 1.0.100), then cargo check also doesn't bat an eye at 1.0.1 not existing in the registry, and silently adopts 1.0.1.