Repository navigation
cargo update should print warnings for incompatible candidates #7167
Description
Currently, if there is a new release of a package that removes a required feature, then cargo update will silently do nothing. This can be a confusing experience because if the user looks at crates.io and sees there is a newer version, it can be difficult to understand why it is not working.
I believe that removing a feature is a breaking semver change, but not everyone knows this or is diligent about managing correct version bumps.
I think cargo update should display a warning if the "newest" candidate is not used because it is missing a feature.
It should probably ignore intermediate candidates, for example starting from version 0.1.0, publish bad release 0.1.1, publish fixed release 0.1.2, then updating from 0.1.0 to 0.1.2 should not produce any warnings.
There are other edge cases to handle (like being able to update from 0.1.0 to 0.1.1, but not 0.1.2).
The following is a test to demonstrate the scenario. The warning at the bottom is just a suggestion, the actual warning will likely be a little different.
#[cargo_test]
fn update_with_missing_feature() {
// Attempting to update a package to a version with a missing feature
// should produce a warning.
Package::new("bar", "0.1.0").feature("feat1", &[]).publish();
let p = project()
.file(
"Cargo.toml",
r#"
[package]
name = "foo"
version = "0.1.0"
[dependencies]
bar = {version="0.1", features=["feat1"]}
"#,
)
.file("src/lib.rs", "")
.build();
p.cargo("generate-lockfile").run();
// Publish an update that is missing the feature.
Package::new("bar", "0.1.1").publish();
p.cargo("update")
.with_stderr(
"\
[WARNING] a newer version of package `bar` is available (`0.1.1`), \
but it does not include the required feature `feat1`, so it will not be updated
",
)
.run();
// Publish a fixed version, should not warn.
Package::new("bar", "0.1.2").feature("feat1", &[]).publish();
p.cargo("update")
.with_stderr(
"\
[UPDATING] `[..]` index
[UPDATING] bar v0.1.0 -> v0.1.2
",
)
.run();
}
Activity
niedzielski commentedon Mar 7, 2020
Extending the "incompatible candidates" criteria,
cargo updateonly considers dependencies that are permitted by the semantic version specified (often in the Cargo.toml). This means that newer forbidden dependencies are not reported and the caller is never made aware that a more involved upgrade is necessary to use the latest and greatest. E.g., considercargo updatewould report that a foo v0.2.2 was available but not v1.0.0. In large Cargo.toml files, this is problematic as there may be many dependencies and it's not practical to determine whether all are fully updated or not.ehuss commentedon Mar 7, 2020
@niedzielski although that is a similar issue, semver-incompatible notifications are part of #4309. You can use the cargo-outdated tool for that.
niedzielski commentedon Mar 7, 2020
@ehuss, very helpful. Thank you! 👍
Auto merge of #13372 - epage:update-report, r=weihanglo
epage commentedon Feb 9, 2024
We now report when a non-latest dependency is selected in #13372 but we don't
epage commentedon Dec 2, 2024
@ehuss is this issue a subset of #7929? Should we close one in favor of the other?
ehuss commentedon Dec 2, 2024
Sure, let's close this in favor of #7929.