cargo update --verbose should explain why a dependency couldn't be updated

[VorpalBlade]

Problem

❯ cargo update 
    Updating crates.io index
     Locking 0 packages to latest compatible versions
note: pass `--verbose` to see 5 unchanged dependencies behind latest
❯ cargo update --verbose
    Updating crates.io index
     Locking 0 packages to latest compatible versions
   Unchanged backtrace v0.3.71 (available: v0.3.74)
   Unchanged hashbrown v0.14.5 (available: v0.15.2)
   Unchanged linux-raw-sys v0.4.15 (available: v0.7.0)
   Unchanged musli v0.0.42 (available: v0.0.126)
   Unchanged zerocopy v0.7.35 (available: v0.8.14)
note: to see how you depend on a package, run `cargo tree --invert --package <dep>@<ver>`
❯ cargo tree --invert --package backtrace
backtrace v0.3.71
└── color-eyre v0.6.3
    ├── konfigkoll v0.1.10 (/home/arvid/src/paketkoll/crates/konfigkoll)
    │   └── xtask v0.1.0 (/home/arvid/src/paketkoll/crates/xtask)
    ├── konfigkoll_core v0.5.1 (/home/arvid/src/paketkoll/crates/konfigkoll_core)
    │   └── konfigkoll v0.1.10 (/home/arvid/src/paketkoll/crates/konfigkoll) (*)
    ├── konfigkoll_script v0.1.8 (/home/arvid/src/paketkoll/crates/konfigkoll_script)
    │   └── konfigkoll v0.1.10 (/home/arvid/src/paketkoll/crates/konfigkoll) (*)
    ├── paketkoll v0.3.8 (/home/arvid/src/paketkoll/crates/paketkoll)
    │   └── xtask v0.1.0 (/home/arvid/src/paketkoll/crates/xtask)
    └── xtask v0.1.0 (/home/arvid/src/paketkoll/crates/xtask)

This is a sub-par explanation of why backtrace wasn't updated.

• Is it a semver thing? No both versions of backtrace are 0.3.x.
• Is it an MSRV issue? No, can't be, I specify rust-version to 1.81.0 across the board in my workspace, and https://lib.rs/crates/backtrace/versions indicates the most recent MSRV is 1.65.
• Is there a a "less than version x" dependency somewhere? When I check color-eyre's Cargo.toml I don't see any.
• Is it because of a yanked version? Doesn't seem so.

I'm at a loss and I believe it would be very useful to be able to see exactly why a dependency wasn't updated by cargo update.

Steps

1. git clone https://github.com/VorpalBlade/paketkoll
2. git checkout 3ec58fac
3. cargo update

Possible Solution(s)

When using --verbose the reason for why a dependency couldn't be updated, especially in trickier cases like this one.

Notes

No response

Version

cargo 1.84.0 (66221abde 2024-11-19)
release: 1.84.0
commit-hash: 66221abdeca2002d318fde6efff516aab091df0e
commit-date: 2024-11-19
host: x86_64-unknown-linux-gnu
libgit2: 1.8.1 (sys:0.19.0 vendored)
libcurl: 8.9.0-DEV (sys:0.4.74+curl-8.9.0 vendored ssl:OpenSSL/1.1.1w)
ssl: OpenSSL 1.1.1w  11 Sep 2023
os: Arch Linux Rolling Release [64-bit]

[VorpalBlade]

Possibly this is a bug in explanation or a bug in that it backtrace wasn't updated. I don't know. I can't tell, and that is a big issue.

[epage]

This appears to be a duplicate of #7929, so closing in favor of that. If there is something I've missed, let us know!

[VorpalBlade]

@epage Maybe it is a duplicate, I don't know if it is a bug that it didn't upgrade that package, or if it is just missing an explanation.

How would I find out what the reason is so that I can determine if it is legitimate or buggy? Because all the reasons I could think of were not it.

[epage]

color-eyre activates the feature gimli-symbolize, see https://docs.rs/crate/color-eyre/latest/source/Cargo.toml.orig#24``

That feature was removed from backtrace.

I found this by running CARGO_LOG=trace cargo update and searching for 0.3.74 and I got this entry

   0.631541494s TRACE main:exec:resolve_with_previous:resolve: cargo::core::resolver::conflict_cache: backtrace = "^0.3.48" adding a skip {PackageId { name: "backtrace", version: "0.3.74", source: "registry `crates-io`" }: Semver, PackageId { name: "color-eyre", version: "0.6.3", source: "registry `crates-io`" }: MissingFeatures("gimli-symbolize")}

Personally, I would be interested in turning this into a hard error but that is a separate conversation that needs a lot of exploration and maybe an Edition.

[Eh2406]

The current resolver does not keep track of enough information to actually give a "complete reason" why something was not updated. Fundamentally all of its reasons have to boil down to "I iterated through all the possibilities", which really isn't all that satisfying. The still in development PubGrub based resolver will give "complete reason", although making them human understandable will take polishing work that has not yet been done.