Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide a way to describe why newer versions are not selected #7929

Open
ehuss opened this issue Feb 25, 2020 · 1 comment
Open

Provide a way to describe why newer versions are not selected #7929

ehuss opened this issue Feb 25, 2020 · 1 comment
Labels
A-dependency-resolution Area: dependency resolution and the resolver C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` S-needs-team-input Status: Needs input from team on whether/how to proceed.

Comments

@ehuss
Copy link
Contributor

ehuss commented Feb 25, 2020

Describe the problem you are trying to solve
Sometimes it can be confusing why newer versions of a package are not selected by the resolver. It would be nice to have some way for Cargo to tell you that there is a newer version available, but it is not able to select it due to some requirement.

There are different reasons this can happen. Some I can think of:

  • Multiple version constraints of different styles. For example one package has "1.0.*", and another has "^1.0".
  • Features were removed in an otherwise semver-compatible release. Packages probably shouldn't do that, but it can still be silently confusing.

This is in spirit with #6199 and #5284, but this is not for errors but for when otherwise compatible versions are skipped.

Describe the solution you'd like
I'm not sure of the best way to convey this information. Maybe cargo update -v could include a detailed message? Or maybe make it part of CARGO_LOG? Or something else?

It could say something like:

info: a newer version of package `bar` is available, 
but it is unable to be selected due to restricted requirements
  `bar` 1.1.0 is available, but
    `somedep`'s requirement `^1.0` selected older version `1.0.0` because
    `restrictor` has the requirement `1.0.*` which prevents the newer version from being selected    

Example
Some examples using Cargo's test notation:

#[cargo_test]
fn describe_restricted_dep() {
    // Example showing a newer version not selected due to an unrelated
    // package's over-restrictive requirements.
    Package::new("dep", "1.0.0").publish();
    Package::new("dep", "1.1.0").publish();
    Package::new("restrictor", "1.0.0")
        .dep("dep", "1.0.*")
        .publish();

    let p = project()
        .file(
            "Cargo.toml",
            r#"
            [package]
            name = "foo"
            version = "1.0.0"

            [dependencies]
            restrictor = "1.0"
            dep = "1.0"
            "#,
        )
        .file("src/lib.rs", "")
        .build();

    p.cargo("update -v").with_stderr("[UPDATING] [..]").run();
}

#[cargo_test]
fn describe_misfeatured_dep() {
    // Example showing a newer version not selected due to missing features.
    Package::new("dep", "1.0.0").feature("f1", &[]).publish();
    Package::new("dep", "1.0.1").publish();

    let p = project()
        .file(
            "Cargo.toml",
            r#"
            [package]
            name = "foo"
            version = "1.0.0"

            [dependencies]
            dep = { version = "1.0", features = ["f1"] }
            "#,
        )
        .file("src/lib.rs", "")
        .build();

    p.cargo("update -v").with_stderr("[UPDATING] [..]").run();
}
@ehuss ehuss added C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` A-dependency-resolution Area: dependency resolution and the resolver labels Feb 25, 2020
@epage
Copy link
Contributor

epage commented Oct 31, 2023

#6666 also asked for this (among other things) but it was closed for #12903 which at least tells people how to enable logging to get the details they want. If we can directly tell them, that'd be great. I worry anything we try will be a lot of work and will be information overload, making it not much better than the logging solution.

@epage epage added S-needs-team-input Status: Needs input from team on whether/how to proceed. S-triage Status: This issue is waiting on initial triage. S-needs-design Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted. and removed S-needs-team-input Status: Needs input from team on whether/how to proceed. S-triage Status: This issue is waiting on initial triage. S-needs-design Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted. labels Oct 31, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-dependency-resolution Area: dependency resolution and the resolver C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` S-needs-team-input Status: Needs input from team on whether/how to proceed.
Projects
None yet
Development

No branches or pull requests

2 participants