--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
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
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.
@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.
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).
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.