Skip to content
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

Refactor: distinguish lockfile from normal =a.b.c dependencies #9840

Closed
Eh2406 opened this issue Aug 25, 2021 · 1 comment · Fixed by #9847
Closed

Refactor: distinguish lockfile from normal =a.b.c dependencies #9840

Eh2406 opened this issue Aug 25, 2021 · 1 comment · Fixed by #9847
Assignees
Labels
A-cargo-api Area: cargo-the-library API and internal code issues

Comments

@Eh2406
Copy link
Contributor

Eh2406 commented Aug 25, 2021

Internally Cargo uses =a.b.c dependencies to tell the Dependency Resolver about things that are fixed by a lockfile. lock_to is used to make the synthetic dependencies, and is_exact to guess if it is synthetic. This works pretty well. We only rarely get a real dependency and a synthetic one confused, and it matters basically never. Except that #9827 now can show the dependency to the user. It would be nice if we could say "which satisfies dependency A > "1.0.0" (pinned to 1.2.3 by the lockfile)" instead of "which satisfies dependency A = "1.2.3"".

My proposed solution is to add a variant to OptVersionReq for the synthetic lockfile dependencies. Something like Locked(Version, VersionReq), So that its display can record the original requirement and the version it is pinned to.

@weihanglo
Copy link
Member

@rustbot claim

I'll address the issue this week

@ehuss ehuss added the A-cargo-api Area: cargo-the-library API and internal code issues label Sep 11, 2021
@bors bors closed this as completed in 4a166de Oct 5, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-cargo-api Area: cargo-the-library API and internal code issues
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants