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

Improve the error message for when a patched dependency doesn't resolve to anything #4678

Open
sunjay opened this Issue Oct 30, 2017 · 7 comments

Comments

Projects
None yet
7 participants
@sunjay
Copy link
Member

sunjay commented Oct 30, 2017

If you were brought here from an error message: It may be that the version of a dependency in your Cargo.lock file does not match the version of your patched dependency. You can often fix this by running cargo update -p <your package name>. We're working on improving this error message to provide better, more detailed suggestions.

If you ran into this error message because of a different reason with a different solution, please let us know in the comments so we can address it. :)


This issue is meant to be a more long term fix than the error message updated in #4607.

From @alexcrichton:

Ideally what we'd do is upon failure do a query again for a more relaxed version constraint, seeing if you just got the wrong version. If that fails we could say that the package doesn't even exist in the source.

More details from @sunjay in the original PR (#4607)

The specific problem that I ran into occurred when I was trying to upgrade the rustfmt submodule in the rust codebase. The rustfmt-nightly dependency changed version numbers and this conflicted with what was in the Cargo.lock file. After some detective work I was able to find the documentation on [patch] which I had never read before and the following relevant paragraphs from some other documentation:

Next up we need to ensure that our lock file is updated to use this new version of uuid so our project uses the locally checked out copy instead of one from crates.io. The way [patch] works is that it'll load the dependency at ../path/to/uuid and then whenever crates.io is queried for versions of uuid it'll also return the local version.

This means that the version number of the local checkout is significant and will affect whether the patch is used. Our manifest declared uuid = "1.0" which means we'll only resolve to >= 1.0.0, < 2.0.0, and Cargo's greedy resolution algorithm also means that we'll resolve to the maximum version within that range. Typically this doesn't matter as the version of the git repository will already be greater or match the maximum version published on crates.io, but it's important to keep this in mind!

If it was not for the person who wrote those docs, I would not have known what to do here!

@kornelski

This comment has been minimized.

Copy link
Contributor

kornelski commented Dec 15, 2017

I've ran into this for the reason as described (I've patched a package with a local dir, cargo updated, and then checked out an earlier version in the patch's target directory), but the cargo update -p <package> command does not fix it — it displays exactly the same message again.

Only deleting Cargo.lock solves the problem for me.

It's still a bug as of rustc 1.33.0-nightly (e40548bc4 2018-12-21)

@Xanewok

This comment has been minimized.

Copy link
Member

Xanewok commented Dec 29, 2017

Encountered this in the exact scenario described by @sunjay, when trying to upgrade rustfmt module in rust repo.
What I did was I upgraded RLS submodule first, which caused Cargo to add

 [[package]]
 name = "rustfmt-nightly"
 version = "0.3.4"
 source = "registry+https://github.com/rust-lang/crates.io-index"

in addition to previously patched, local rustfmt [[package]] with 0.3.2 version.
Then, when I tried to checkout new 0.3.4 version of rustfmt module, I got this error. cargo update -p rustfmt-nightly didn't help.
What I did what was @pornel suggested, but I only deleted the old

 [[package]]
 name = "rustfmt-nightly"
 version = "0.3.2"

entry and this fixed the issue.

@Eh2406

This comment has been minimized.

Copy link
Contributor

Eh2406 commented Mar 22, 2018

@alexcrichton did you fix this recently?

@alexcrichton

This comment has been minimized.

Copy link
Member

alexcrichton commented Mar 22, 2018

@Eh2406 I don't think I purposely did but if it was fixed as a side product that'd be nice! (and if so we should certainly add a test for this)

ishitatsuyuki added a commit to rust-lang/rust that referenced this issue Apr 6, 2018

bootstrap: Remove the fast path
This is rarely noticed, but when you have old submodules, not updating them will cause you run into rust-lang/cargo#4678.

kennytm added a commit to kennytm/rust that referenced this issue Apr 6, 2018

Rollup merge of rust-lang#49721 - rust-lang:ishitatsuyuki-patch-1, r=…
…Mark-Simulacrum

bootstrap: Remove the help fast path

This is rarely noticed, but when you have old submodules, not updating them will cause you run into rust-lang/cargo#4678.

kennytm added a commit to kennytm/rust that referenced this issue Apr 7, 2018

Rollup merge of rust-lang#49750 - ishitatsuyuki:boot-no-fast, r=Mark-…
…Simulacrum

bootstrap: Remove the fast path

This is rarely noticed, but when you have old submodules, not updating them will cause you run into rust-lang/cargo#4678.

(Reopen of rust-lang#49721)

r? @alexcrichton

toidiu pushed a commit to toidiu/rust that referenced this issue Apr 10, 2018

bootstrap: Remove the fast path
This is rarely noticed, but when you have old submodules, not updating them will cause you run into rust-lang/cargo#4678.

U007D added a commit to humanenginuity/rust that referenced this issue May 6, 2018

killercup added a commit to killercup/quicli that referenced this issue Jun 10, 2018

Update lock file
Ran `cargo update -p quicli` because
rust-lang/cargo#4678 told me too.
@stale

This comment has been minimized.

Copy link

stale bot commented Sep 18, 2018

As there hasn't been any activity here in over 6 months I've marked this as stale and if no further activity happens for 7 days I will close it.

I'm a bot so this may be in error! If this issue should remain open, could someone (the author, a team member, or any interested party) please comment to that effect?

The team would be especially grateful if such a comment included details such as:

  • Is this still relevant?
  • If so, what is blocking it?
  • Is it known what could be done to help move this forward?

Thank you for contributing!

(The cargo team is currently evaluating the use of Stale bot, and using #6035 as the tracking issue to gather feedback.)

If you're reading this comment from the distant future, fear not if this was closed automatically. If you believe it's still an issue please leave a comment and a team member can reopen this issue. Opening a new issue is also acceptable!

@stale stale bot added the stale label Sep 18, 2018

@sunjay

This comment has been minimized.

Copy link
Member

sunjay commented Sep 18, 2018

This is likely still an issue and it is probably that no one has gotten to it yet.

@stale stale bot removed the stale label Sep 18, 2018

@jethrogb

This comment has been minimized.

Copy link
Contributor

jethrogb commented Oct 31, 2018

If you got here when trying to compile rustc, make sure to update your submodules: git submodule update --init --recursive

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment