-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
More update --breaking
tests
#14049
More update --breaking
tests
#14049
Conversation
r? @weihanglo rustbot has assigned @weihanglo. Use |
r? epage |
372ff8f
to
7bdf956
Compare
7bdf956
to
3a45d6e
Compare
tests/testsuite/update.rs
Outdated
p.cargo("update -Zunstable-options --breaking [email protected]") | ||
.masquerade_as_nightly_cargo(&["update-breaking"]) | ||
.with_stderr( | ||
// FIXME: This is wrong. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I found another problem. We're not matching incompatible
with [email protected]
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But maybe that's not a bug. Strictly speaking, 1.0.0
does not match the version requirement 1.0
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Anyway, I pushed a fix.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Think of this feature as a specially named --force
flag. They identified the entry they want to update so we should.
What we also need a test for is if they specify a compatible version that isn't in the lockfile.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm actually not using the lock file. This should work whether or not there is a lock file. I'm just checking if the version matches the version req.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thats an implementation detail while I'm talking of user-facing semantics. We should match spec
behavior with cargo update
without --breaking
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Imagine a non-existing [email protected]
. When run without a lock file, cargo update [email protected]
does not complain. Then, if the same command is run again (now with a lock file), it complains about [email protected]
not matching any packages. So it is not idempotent.
Is it OK if cargo update --breaking [email protected]
also doesn't complain, whether or not there is a lock file?
If not OK, we'll have to query a previous_resolve
just for this error message. And it might be a good idea to go back to reusing the ops::update_lockfile
that the non-breaking update is running (but then having to make changes to keep
). In any case, can we put that in a separate PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@epage This may or may not be a task to put on the task list, but it depends on your answer to the question about cargo update --breaking [email protected]
not complaining.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's put it in the task list either way and not block this conversation further.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
FYI, this is changed in #14140. If there isn't a lock file, update -Zunstable-options --breaking [email protected]
will do this:
[UPDATING] `dummy-registry` index
[LOCKING] 3 packages to latest compatible versions
[ADDING] incompatible v1.0.1 (latest: v2.0.0)
If there is a lock file, it will do this:
[ERROR] package ID specification `[email protected]` did not match any packages
Did you mean one of these?
[email protected]
2de4c24
to
b3a1a50
Compare
If I'm understanding, thats a question of whether non-workspace path dependencies should be affected by this (and whether we should error if nothing matched). I think this makes a good case for erroring. Our mental model is this is a specialized force, so it makes sense the lockfile can update when others can't if we error. As for local deps like this, we should make this a task in the tracking issue to verify the general approach of cargo wrt mutations (cargo add, cargo fix, etc). |
Looks like this is actually consistent. We can not run |
901f78e
to
0d59dfc
Compare
@epage I consider this PR ready on my part now. Awaiting further review comments. |
0d59dfc
to
28f57be
Compare
28f57be
to
70c01f9
Compare
While #14115 is not about bumping SemVer-breaking versions, this behavior described in #14115 (comment) could be a thing to consider supporting or adding a test: |
tests/testsuite/update.rs
Outdated
/// keyed on dependency name and source, we also need to know which manifest | ||
/// files to update and which to keep unchanged, because they may be pinned or |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- this feels weird for the test to be prescriptive on the implementation in a comment
- This isn't right. Its not just files but individual dependencies. You could have renamed in one dependency block but not another
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I removed that part of the comment, moved the rest (updated) to the implementation, and added a test case for mixed pinning within the same manifest.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The comment removal was done in a later commit. Should it be done in the initial commit?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed.
70c01f9
to
78e10b7
Compare
2dcc815
to
690f6a0
Compare
tests/testsuite/update.rs
Outdated
let root_manifest = p.read_file("Cargo.toml"); | ||
let foo_manifest = p.read_file("foo/Cargo.toml"); | ||
let bar_manifest = p.read_file("bar/Cargo.toml"); | ||
let baz_manifest = p.read_file("baz/Cargo.toml"); | ||
|
||
assert_e2e().eq( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: Personally, I'd read next to use to keep knowledge as local as possible
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed.
tests/testsuite/update.rs
Outdated
let foo_manifest = p.read_file("foo/Cargo.toml"); | ||
let bar_manifest = p.read_file("bar/Cargo.toml"); | ||
let baz_manifest = p.read_file("baz/Cargo.toml"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it work to give these workspace members names tied to their role in the test? For example, they can be "pinned", "unpinned", "mixed-pinned". That'd make it easier to follow what the test is doing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed.
e9fd85a
to
5434977
Compare
@epage Ready for review again. |
5434977
to
f41bdc1
Compare
Thanks! @bors r+ |
.masquerade_as_nightly_cargo(&["update-breaking"]) | ||
.with_status(101) | ||
.with_stderr_data(str![[r#" | ||
[ERROR] expected a version like "1.32" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hadn't notice this before. This error message is bad. We should at least be calling out that we are parsing a package id spec
Existing behavior:
$ cargo update clap@foo
error: invalid package ID specification: `clap@foo`
Caused by:
expected a version like "1.32"
(again, task is list is fine)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added.
☀️ Test successful - checks-actions |
Update cargo 23 commits in 4ed7bee47f7dd4416b36fada1909e9a62c546246..a515d463427b3912ec0365d106791f88c1c14e1b 2024-06-25 16:28:22 +0000 to 2024-07-02 20:53:36 +0000 - test: migrate rust_version and rustc* to snapbox (rust-lang/cargo#14177) - test: mirgate fix* and future_incompat_report to snapbox (rust-lang/cargo#14173) - test:migrate `edition/error` to snapbox (rust-lang/cargo#14175) - chore(deps): update compatible (rust-lang/cargo#14174) - refactor(source): Clean up after PathSource/RecursivePathSource split (rust-lang/cargo#14169) - test: Migrate some files to snapbox (rust-lang/cargo#14132) - test: fix several assertions (rust-lang/cargo#14167) - test: replace glob with explicit unordered calls (rust-lang/cargo#14166) - Make it clear that `CARGO_CFG_TARGET_FAMILY` is multi-valued (rust-lang/cargo#14165) - Document `CARGO_CFG_TARGET_ABI` (rust-lang/cargo#14164) - test: Migrate git to snapbox (rust-lang/cargo#14159) - test: migrate some files to snapbox (rust-lang/cargo#14158) - test: migrate registry and registry_auth to snapbox (rust-lang/cargo#14149) - gix: remove `revision` feature from cargo (rust-lang/cargo#14160) - test: migrate package* and publish* to snapbox (rust-lang/cargo#14130) - More `update --breaking` tests (rust-lang/cargo#14049) - test: migrate clean to snapbox (rust-lang/cargo#14096) - Allow `unexpected_builtin_cfgs` lint in `user_specific_cfgs` test (rust-lang/cargo#14153) - test: migrate search, source_replacement and standard_lib to snapbox (rust-lang/cargo#14151) - Docs: Update config summary to include missing keys. (rust-lang/cargo#14145) - test: migrate `dep_info/diagnostics/direct_minimal_versions` to snapbox (rust-lang/cargo#14143) - Docs: Remove duplicate `strip` section. (rust-lang/cargo#14146) - Docs: Fix curly quotes in config docs. (rust-lang/cargo#14144)
…te-breaking, r=weihanglo Improved error message when `update --breaking` invalid spec. Improves an error message when trying to do `cargo update --breaking clap@foo`: ``` - [ERROR] expected a version like "1.32" + [ERROR] invalid package ID specification: `clap@foo` + Caused by: + expected a version like "1.32" ``` Related to #12425. Fixes an item [here](#12425 (comment)), as noted [here](#14049 (comment)).
…te-breaking, r=weihanglo Improved error message when `update --breaking` invalid spec. Improves an error message when trying to do `cargo update --breaking clap@foo`: ``` - [ERROR] expected a version like "1.32" + [ERROR] invalid package ID specification: `clap@foo` + Caused by: + expected a version like "1.32" ``` Related to #12425. Fixes an item [here](#12425 (comment)), as noted [here](#14049 (comment)).
Related to #12425 (comment) in #12425.