-
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
move up looking at index summary enum #12749
Conversation
r? @ehuss (rustbot has picked a reviewer for you, use r? to override) |
r? @epage |
src/cargo/sources/registry/mod.rs
Outdated
.precise_registry_version(dep.package_name().as_str()) | ||
.filter(|(c, _)| req.matches(c)) | ||
{ | ||
req.lock_to(&requested); |
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.
lock_to
was changed have the same semantics as --precise
, but it's possible we should have two different kind of locked requirements.
callback, | ||
false | ||
)?); | ||
ready!(self.query_inner_with_online(name, req, load, callback, false)?); | ||
if called { |
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.
by moving filtering of yanked versions from beneath this code to above this code there may be situations in which called
is now different. I don't think this will break anything, tests still pass, but it needs more thinking than I gave it.
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.
So we query offline and see if anything came up, if it did, we move on. We then query online.
So I guess in theory if what the offline check found was yanked, then we might move on, filter it out, and then error instead of switching to on. Whether that can actually happen and cause problems needs a wider view of this stack than I have at this time. From how this is all behaving (this should likely only happen with locked packages which will be allow-listed), I'm assuming it will be 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.
That analysis sounds correct.
(this should likely only happen with locked packages which will be allow-listed)
I think the problematic case is that there is a downloaded version that has been yanked and is not in the allowed list. The old behavior would filter out the version because it yanked and not in the allow list, meaning that the first pass would see no candidates and so fallback to the second pass. Whereas, the new code will see the yanked version witch is available off-line so return it is the only candidate not falling back to the second pass.
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.
So it looks like we are allowing yanked in that first pass, which is fine because its a lockfile, bypassing this problem. Do I have that right?
☔ The latest upstream changes (presumably #12796) made this pull request unmergeable. Please resolve the merge conflicts. |
For anyone following along this is block on #12772 |
If there's a version in the lock file only use that exact version ### What does this PR try to resolve? Generally, cargo is of the opinion that semver metadata should be ignored. It's is relevant to dependency resolution as any other description of the version, just like the description field in cargo.toml. If your registry has two versions that only differing metadata you get the bugs you deserve. We implement functionality to make it easier for our users or for us to maintain. ~~So let's use `==` because it's less code to write and test.~~ We also believe that lock files should ensure reproducibility and protect against mutations from the registry. In this circumstance these two goals are in conflict, and this PR picks reproducibility. If the lock file tells us that there is a version called `1.0.0+bar` then we should not silently use `1.0.0+foo` even though they have the same version. This is one of the alternatives/follow-ups discussed in #11447. It was separated from #12749, to allow for separate discussion and because I was being too clever by half. ### How should we test and review this PR? All tests still pass except for the ones that were removed. The removed tests were only added to verify the on intuitive behavior of the older implementation in #9847.
Rebased and updated to have a different variant of |
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.
Feel free to r= me when its ready
I cannot reproduce the build failures locally. |
@bors r=epage |
move up looking at index summary enum This builds on the work from #12643 and the discussion of the overall approach is at https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/better.20error.20messages.20for.20filtered.20versions.2E ### What does this PR try to resolve? This uses the enum added in #12643 to delay making decisions about yanked and `–– precise` versions until higher in the stack. ### How should we test and review this PR? This is an internal re-factoring and all the tests still pass. BUT, this is also tricky interleaved code where small changes may have important impacts to semantics. ### Additional information I will try and call out potentially breaking changes as inline comments. If any of these are controversial enough to deserve separate discussion I'm happy split it into separate PR's.
💔 Test failed - checks-actions |
@bors r=epage |
☀️ Test successful - checks-actions |
Update cargo 8 commits in df3509237935f9418351b77803df7bc05c009b3d..708383d620e183a9ece69b8fe930c411d83dee27 2023-10-24 23:09:01 +0000 to 2023-10-27 21:09:26 +0000 - feat(doc): Print the generated docs links (rust-lang/cargo#12859) - feat(toml): Allow version-less manifests (rust-lang/cargo#12786) - Remove outdated option to `-Zcheck-cfg` warnings (rust-lang/cargo#12884) - Remove duplicate binaries during install (rust-lang/cargo#12868) - refactor(shell): Write at once rather than in fragments (rust-lang/cargo#12880) - docs(ref): Link to docs.rs metadata table (rust-lang/cargo#12879) - docs(contrib): Describe how to add a new package (rust-lang/cargo#12878) - move up looking at index summary enum (rust-lang/cargo#12749) r? ghost
query{_vec} use IndexSummary This builds on the work from #12749 and the discussion of the overall approach is at https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/better.20error.20messages.20for.20filtered.20versions.2E ### What does this PR try to resolve? Changing the two traits `Registry` and `Source` to use the new `IndexSummary' involves a lot of changes all throughout the code base. This would be hard to review if it also included any logic changes. So this PR is just adding the type to the trait and immediately unwrapping every place it is used. The hope is that reviewing changes to logic/ergonomics will be easier to review once the mechanical changes have been merged. ### How should we test and review this PR? This is an internal re-factoring and all the tests still pass.
This builds on the work from #12643 and the discussion of the overall approach is at https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/better.20error.20messages.20for.20filtered.20versions.2E
What does this PR try to resolve?
This uses the enum added in #12643 to delay making decisions about yanked and
–– precise
versions until higher in the stack.How should we test and review this PR?
This is an internal re-factoring and all the tests still pass. BUT, this is also tricky interleaved code where small changes may have important impacts to semantics.
Additional information
I will try and call out potentially breaking changes as inline comments. If any of these are controversial enough to deserve separate discussion I'm happy split it into separate PR's.