Don't require cargo update when bumping versions
#5215
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
r? @matklad (rust_highfive has picked a reviewer for you, use r? to override) |
matklad
reviewed
Mar 20, 2018
tests/testsuite/update.rs
Outdated
| ) | ||
| .build(); | ||
|
|
||
| assert_that(p.cargo("build").env("RUST_LOG", "cargo=trace"), |
tests/testsuite/update.rs
Outdated
| name = "bar" | ||
| version = "0.2.0-alpha" | ||
| authors = [] | ||
|
|
src/cargo/ops/resolve.rs
Outdated
| let mut avoid_locking = HashSet::new(); | ||
| for node in resolve.iter() { | ||
| if !keep(&node) { | ||
| add_deps(resolve, node, &mut avoid_locking); | ||
| } else if node.source_id().is_path() { | ||
| if let Ok(path) = node.source_id().url().to_file_path() { |
There was a problem hiding this comment.
I wonder if it makes sense to somehow reshuffle utility methods, so as to avoid if is_path() { url().to_file_path() } pattern
One historical annoyance I've always had with Cargo that I've found surprising is that in some situations when you bump version numbers you'll have to end up running `cargo update` later on to get everything to build. You get pretty wonky error messages in this case as well saying a package doesn't exist when it clearly does at a particular location! I've had difficulty historically nailing down a test case for this but it looks like we ironically already had one in our test suite and I also jury-rigged up one from a case I ran into in the wild today.
alexcrichton
force-pushed
the
update-version
branch
from
c9a1030
to
0deaae9
Compare
|
@bors: r=matklad |
|
📌 Commit 0deaae9 has been approved by |
bors
added a commit
that referenced
this pull request
Mar 20, 2018
Don't require `cargo update` when bumping versions One historical annoyance I've always had with Cargo that I've found surprising is that in some situations when you bump version numbers you'll have to end up running `cargo update` later on to get everything to build. You get pretty wonky error messages in this case as well saying a package doesn't exist when it clearly does at a particular location! I've had difficulty historically nailing down a test case for this but it looks like we ironically already had one in our test suite and I also jury-rigged up one from a case I ran into in the wild today.
|
☀️ Test successful - status-appveyor, status-travis |
alexcrichton
added a commit
to alexcrichton/cargo
that referenced
this pull request
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 pull request
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 pull request
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
One historical annoyance I've always had with Cargo that I've found surprising
is that in some situations when you bump version numbers you'll have to end up
running
cargo updatelater on to get everything to build. You get pretty wonkyerror messages in this case as well saying a package doesn't exist when it
clearly does at a particular location!
I've had difficulty historically nailing down a test case for this but it looks
like we ironically already had one in our test suite and I also jury-rigged up
one from a case I ran into in the wild today.