Why doesn't `cargo build` update yanked dependencies?

Without --locked, I expected that even with a Cargo.lock file containing a yanked version of a dependency, rebuilding with cargo build would discover the yanked dependency and, if possible, update it.

However, this doesn't seem to be the case; even without --locked, cargo check uses the version of the dependency that was specified in Cargo.lock, even if a newer semver-compatible version is available. To remove the yanked dependency from Cargo.lock, it seems I need to either manually delete the lock file or run cargo update.

Why is this? The behavior would make sense for --locked but seems strange without it.

AFAICT this behavior is intentional. cargo build, well, builds. And it does so by following the contents of Cargo.lock, not by messing about with them. The latter is what, as you mention, cargo update is for.
The 2 are orthogonal operations and thus orthogonal cargo subcommands.

Consider this: if cargo build did automatic updates, then offline building would be impossible, which would be a misfeature.

1 Like

@jjpe Offline building would of course be possible with --locked. Presumably the existence of --locked implies that offline building is already impossible without --locked... doesn't it?

The point of Cargo.lock is reproducible builds -- i.e. not updating your deps unless necessary (due to a change in your dependency requirements -- like specifying a new major version in Cargo.toml, or because you added a new dependency).

The roll of build --locked is to disable updates even if necessary due to changes in your dependency requirements.


Oh, okay, the part I was not understanding from the docs was that --locked only adds a new error path, i.e. if cargo build --locked succeeds it will always produce the same dependency tree that cargo build would have.

Is there a way to update (or even downgrade!) just the yanked dependencies in the dependency tree? That would be useful for someone trying to make the minimal set of changes necessary to build without dependencies that have been yanked.

1 Like

I don't think so but agree it sounds useful. Especially if we some day get explanations for why something was yanked (to be able to discern between "security problem" and "zealously unmaintained" say).


I've opened a feature-request for cargo audit fix to un-lock yanked package versions: Request: cargo fix should un-lock yanked packages · Issue #917 · rustsec/rustsec · GitHub


This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.