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

Cargo fails to resolve when adding a git dependency incompatible with a locked crate version but compatible with the Cargo.toml requirement #14916

Open
x-hgg-x opened this issue Dec 10, 2024 · 1 comment
Labels
A-dependency-resolution Area: dependency resolution and the resolver C-bug Category: bug S-triage Status: This issue is waiting on initial triage.

Comments

@x-hgg-x
Copy link
Contributor

x-hgg-x commented Dec 10, 2024

Problem

Cargo fails to resolve when adding a git dependency incompatible with a locked crate version but compatible with the Cargo.toml requirement.

Steps

  • Add libc 0.2.0 in the lockfile:
cargo add libc@=0.2.0
  • Relax version requirement for libc, while keeping the same version in the lockfile:
  • Add the git version of cc with the parallel feature.
cargo add cc -F parallel --git https://github.com/rust-lang/cc-rs --tag cc-v1.2.3

It depends on libc >= 0.2.87, so the libc version in the lockfile should be upgraded, but it errors instead.

Output:

error: failed to select a version for `libc`.
    ... required by package `jobserver v0.1.30`
    ... which satisfies dependency `jobserver = "^0.1.30"` of package `cc v1.2.3 (https://github.com/rust-lang/cc-rs?tag=cc-v1.2.3#1d96c830)`
    ... which satisfies git dependency `cc` of package `test-cargo v0.1.0 (/home/runner/Bureau/test-cargo)`
versions that meet the requirements `^0.2.87` are: 0.2.168, 0.2.167, 0.2.166, 0.2.164, 0.2.163, 0.2.162, 0.2.161, 0.2.160, 0.2.159, 0.2.158, 0.2.157, 0.2.156, 0.2.155, 0.2.153, 0.2.152, 0.2.151, 0.2.150, 0.2.149, 0.2.148, 0.2.147, 0.2.146, 0.2.144, 0.2.143, 0.2.142, 0.2.141, 0.2.140, 0.2.139, 0.2.138, 0.2.137, 0.2.136, 0.2.135, 0.2.134, 0.2.133, 0.2.132, 0.2.131, 0.2.129, 0.2.127, 0.2.126, 0.2.125, 0.2.124, 0.2.123, 0.2.122, 0.2.121, 0.2.120, 0.2.119, 0.2.118, 0.2.117, 0.2.116, 0.2.115, 0.2.114, 0.2.113, 0.2.112, 0.2.111, 0.2.109, 0.2.108, 0.2.107, 0.2.106, 0.2.105, 0.2.104, 0.2.103, 0.2.102, 0.2.101, 0.2.100, 0.2.99, 0.2.98, 0.2.97, 0.2.96, 0.2.95, 0.2.94, 0.2.93, 0.2.92, 0.2.91, 0.2.90, 0.2.89, 0.2.88, 0.2.87

all possible versions conflict with previously selected packages.

  previously selected package `libc v0.2.0`
    ... which satisfies dependency `libc = "^0.2.0"` (locked to 0.2.0) of package `test-cargo v0.1.0 (/home/runner/Bureau/test-cargo)`

failed to select a version for `libc` which could resolve this conflict

Possible Solution(s)

No response

Notes

  • The workaround here is to edit the lockfile manually or delete it completely.
  • Adding the registry version instead of the git version (with cargo add cc@=1.2.3) works as expected.

Version

cargo 1.83.0 (5ffbef321 2024-10-29)
release: 1.83.0
commit-hash: 5ffbef3211a8c378857905775a15c5b32a174d3b
commit-date: 2024-10-29
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: Linux Mint 22.0.0 (wilma) [64-bit]
@x-hgg-x x-hgg-x added C-bug Category: bug S-triage Status: This issue is waiting on initial triage. labels Dec 10, 2024
@x-hgg-x x-hgg-x changed the title Cargo fails to resolve when adding a git dependency incompatible with a locked crate version but compatible with its Cargo.toml requirement Cargo fails to resolve when adding a git dependency incompatible with a locked crate version but compatible with the Cargo.toml requirement Dec 10, 2024
@epage epage added the A-dependency-resolution Area: dependency resolution and the resolver label Dec 10, 2024
@epage
Copy link
Contributor

epage commented Dec 10, 2024

I think this is another variant of #10307, see #10307 (comment)

Cargo's attempt to use the previous lock file as the source of how to perform version resolution is a bit too strict here and simply requires that the old version in the lock file must be used, when in fact it should be updated to account for the incremental edit to the manifest.

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-bug Category: bug S-triage Status: This issue is waiting on initial triage.
Projects
None yet
Development

No branches or pull requests

2 participants