Regression: Cargo nightly updates registry on every build with "path" crate #5257
Comments
|
@bill-myers could you give an example where this is happening? I don't seem able to reproduce locally |
|
The following commands reproduce it for me: Running "cargo +nightly build" results in a registry update every time, while "cargo +stable build" (with Rust 1.25) doesn't. It might be caused by something the "enum-map" crate is doing, since just creating a new library instead of cloning "enum-map" doesn't trigger it. |
|
Yep, I've reproduced it, thanks a lot, @bill-myers ! |
|
Attempting to debug this, logs from nightly: and with stable The interesting bit is cc @Eh2406 :-) |
|
That is from hear which was added in #5180 So cc @alexcrichton :-) |
|
Ok, so the buggy logic is here I think: cargo/src/cargo/ops/resolve.rs Lines 457 to 466 in 4389f62 Looks like if the |
I got lost in the double negatives. Do you see how to fix it? |
|
@Eh2406 I have no idea how to fix it, it would be awesome if you take a look :) |
|
I'm taking a look at this currently |
|
I've posted a fix in #5288 |
alexcrichton
added a commit
to alexcrichton/cargo
that referenced
this issue
Apr 3, 2018
Discovered in rust-lang#5257 the changes in rust-lang#5215 were slightly too aggressively poisoning sources to require updates, thinking that a manifest changed when it actually hadn't. Non-workspace-member path dependencies with optional/dev-dependencies don't show up in the lock file, so the previous logic would recognize this and think that the dependency missing from the lock file was just added and would require a registry update. The fix in this commit effectively just skips all of these dependencies in non-workspace members. This means that this will be slightly buggy if an optional dependency that's activated is added, but that's hopefully something we can tackle later. Closes rust-lang#5257
bors
added a commit
that referenced
this issue
Apr 3, 2018
Less aggressively poison sources on builds Discovered in #5257 the changes in #5215 were slightly too aggressively poisoning sources to require updates, thinking that a manifest changed when it actually hadn't. Non-workspace-member path dependencies with optional/dev-dependencies don't show up in the lock file, so the previous logic would recognize this and think that the dependency missing from the lock file was just added and would require a registry update. The fix in this commit effectively just skips all of these dependencies in non-workspace members. This means that this will be slightly buggy if an optional dependency that's activated is added, but that's hopefully something we can tackle later. Closes #5257
matklad
pushed a commit
to matklad/cargo
that referenced
this issue
Apr 4, 2018
Discovered in rust-lang#5257 the changes in rust-lang#5215 were slightly too aggressively poisoning sources to require updates, thinking that a manifest changed when it actually hadn't. Non-workspace-member path dependencies with optional/dev-dependencies don't show up in the lock file, so the previous logic would recognize this and think that the dependency missing from the lock file was just added and would require a registry update. The fix in this commit effectively just skips all of these dependencies in non-workspace members. This means that this will be slightly buggy if an optional dependency that's activated is added, but that's hopefully something we can tackle later. Closes rust-lang#5257
|
I think I still observe this on master, here is a super-non-minimal example: |
alexcrichton
added a commit
to alexcrichton/cargo
that referenced
this issue
Apr 6, 2018
This commit extends the fix in rust-lang#5288 by moving the logic added farther up in the loop over package dependencies. This means that we won't recursively look at optional/dev path dependencies which aren't members of the workspace. This should fix the new issue that came up in rust-lang#5257 Closes rust-lang#5257
bors
added a commit
that referenced
this issue
Apr 6, 2018
Fix another issue of poisoning too eagerly This commit extends the fix in #5288 by moving the logic added farther up in the loop over package dependencies. This means that we won't recursively look at optional/dev path dependencies which aren't members of the workspace. This should fix the new issue that came up in #5257 Closes #5257
alexcrichton
added a commit
to alexcrichton/cargo
that referenced
this issue
Apr 6, 2018
This commit extends the fix in rust-lang#5288 by moving the logic added farther up in the loop over package dependencies. This means that we won't recursively look at optional/dev path dependencies which aren't members of the workspace. This should fix the new issue that came up in rust-lang#5257 Closes rust-lang#5257
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When one of the dependencies is local, specified using "path", Cargo updates the registry on every build.
I think this was supposed to be fixed, but is present with nightly Rust (but not stable).
The text was updated successfully, but these errors were encountered: