fix(install): use packaged lockfile by default by gmemuriuki · Pull Request #17388 · rust-lang/cargo

gmemuriuki · 2026-08-24T15:37:52Z

What does this PR try to resolve?

This PR closes #7169

cargo build uses an existing Cargo.lock, while cargo install previously ignored a package's Cargo.lock file unless --locked was passed. As a result, building and testing a binary could use one set of dependency version while installing the same binary selected another.

This can cause installation to fail even though the package built and tested successfully. This also leaves maintainers supporting dependency versions they didn't test or sign-up for.

Following Cargo Team Decision,
this PR makes cargo install use the available lockfile by default. This gives cargo install the existing behavior of cargo install --locked.

--locked remains accepted but it is a no-op. When a package does not contain a lockfile, Cargo fallback to resolving its deps normally. Explicitly passing --locked still emits the existing missing-lockfile warning.

The warning for yanked deps is preserved, but it's suggestion to retry without --locked is removed because doing so no longer changes dep resolution.

Deprecating --locked and adding an option to ignore the packaged lockfile remains a separate effort to be considered as discussed in the decision.

How to test and review this PR?

There are four commits structured in this manner:

Make the help attached to yanked-dependency warning optional without changing the existing behavior
Add tests to verify that cargo install --locked honors packaged lockfile.
Change installation behavior, update the affected tests, and update the generated documentation.
Remove now obsolete ignore_lock workspace state and resolver path.

Test covers

Registry installation without the packaged lockfile by default.
Path installation using it's lockfile by default.
--locked remaining accepted and producing the same resolution.
Falling back to normal resolution when no published lockfile exists.
Git installation without a lockfile
Yanked dependencies continuing to warn without suggesting installation without --locked.
The existing cargo-package yanked-dependency help remaining unchanged.

The following tests were run:

cargo test --test testsuite -- install::install_respects_lock_file
cargo test --test testsuite -- install::install_path_respects_lock_file
cargo test --test testsuite -- install::locked_install_
cargo test --test testsuite -- install::install_without_published_lockfile
cargo test --test testsuite -- install::git_repo
cargo test --test testsuite -- publish_lockfile::warn

rustbot · 2026-08-24T15:37:57Z

Thanks for the pull request, and welcome! The Rust Project has assigned @weihanglo (or someone else) to review your changes, you should hear from them (or someone else) within the next two weeks.

Please see the contribution instructions for more information.

Why was this reviewer chosen?

The reviewer was selected based on:

Owners of files modified in this PR: @epage, @weihanglo
@epage, @weihanglo expanded to epage, weihanglo
Random selection from epage, weihanglo

weihanglo · 2026-08-24T16:58:35Z

-        .with_status(101)
-        .run();
-    p.cargo("install --path . --locked").run();
+    p.cargo("install --path .").run();


This drops the snapshot asserting [..]not rust[..]. Was it intentional? Otherwise we might want to keep it.

View changes since the review

weihanglo · 2026-08-24T16:59:41Z

-        .run();
-    p.cargo("install --path . --locked").run();
+    p.cargo("install --path .").run();
+    p.cargo("install --path . --locked --force").run();


This --locked --force change is better to be in its own test commit, prior to the fix commit, and we might want to have the same assertion verifying it actually respects the lockfile.

View changes since the review

Okay, that's fine. I'll have it ready.

weihanglo · 2026-08-24T17:00:51Z

Thanks for the contribution. Would you mind cleaning up the template strings in the PR description?

epage · 2026-08-25T03:36:45Z

btw thank you for moving this forward! The recent arrayref situation shows how important this change is!

gmemuriuki · 2026-08-25T13:43:32Z

🙏 Happy to help. I'd love to get more involved with cargo even after this.

weihanglo · 2026-08-26T19:37:19Z

@gmemuriuki You probably want to rebase onto master branch to fix the failed job: https://github.com/rust-lang/cargo/actions/runs/33005586808/job/98298352305?pr=17388

gmemuriuki · 2026-08-26T19:41:42Z

Sure, I'm on it.

Keep explicit --locked coverage independent from tests for cargo install's default lockfile behavior.

rustbot · 2026-08-27T20:21:41Z

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

Make registry and path installs honor Cargo.lock without requiring --locked. Keep fallback behavior when no lockfile is available, including the compatibility warning for explicit --locked.

Cargo install now honors an an available lockfile, so no caller needs Workspace::ignore_lock. Remove the unused state and unreachable resolver and MSRV-help branches while retaining the no-lockfile yanked-check guard.

weihanglo

Looks good. Maybe we can polish doc a bit but not a blocker

View changes since this review

epage · 2026-08-28T02:01:02Z

@rfcbot fcp merge

This PR implements the policy we decided on in the 2026-04-28 meeting as described at #7169 (comment)

rust-rfcbot · 2026-08-28T02:01:05Z

@epage has proposed to merge this. The next step is review by the rest of the tagged team members:

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

weihanglo · 2026-08-28T03:21:35Z

@rfcbot reviewed

arlosi · 2026-09-01T19:04:59Z

@rfcbot reviewed

rust-rfcbot · 2026-09-01T19:05:09Z

🔔 This is now entering its final comment period, as per the review above. 🔔

rustbot assigned weihanglo Aug 24, 2026

rustbot added A-cli-help Area: built-in command-line help A-documenting-cargo-itself Area: Cargo's documentation A-workspaces Area: workspaces Command-install Command-package S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 24, 2026

epage reviewed Aug 24, 2026

View reviewed changes

Comment thread src/workspace/workspace.rs Outdated

Comment thread src/ops/cargo_install.rs

weihanglo reviewed Aug 24, 2026

View reviewed changes

gmemuriuki force-pushed the fix/7169-install-use-lockfile branch from 5ad02ea to 07a27bc Compare August 26, 2026 19:31

epage reviewed Aug 26, 2026

View reviewed changes

Comment thread tests/testsuite/install.rs

epage reviewed Aug 26, 2026

View reviewed changes

Comment thread tests/testsuite/install.rs

epage reviewed Aug 26, 2026

View reviewed changes

Comment thread tests/testsuite/install.rs

gmemuriuki added 2 commits August 27, 2026 23:04

refactor: make yanked dependency help optional

78f8bc7

test: verify locked installs honor lockfiles

baffddf

Keep explicit --locked coverage independent from tests for cargo install's default lockfile behavior.

gmemuriuki force-pushed the fix/7169-install-use-lockfile branch from 07a27bc to 61aec32 Compare August 27, 2026 20:21

gmemuriuki added 2 commits August 28, 2026 00:16

fix(install): use lockfiles by default

8b65910

Make registry and path installs honor Cargo.lock without requiring --locked. Keep fallback behavior when no lockfile is available, including the compatibility warning for explicit --locked.

refactor: remove obsolete ignore-lock state

b7c0e0f

Cargo install now honors an an available lockfile, so no caller needs Workspace::ignore_lock. Remove the unused state and unreachable resolver and MSRV-help branches while retaining the no-lockfile yanked-check guard.

gmemuriuki force-pushed the fix/7169-install-use-lockfile branch from 61aec32 to b7c0e0f Compare August 27, 2026 21:19

weihanglo approved these changes Aug 28, 2026

View reviewed changes

epage added the T-cargo Team: Cargo label Aug 28, 2026

rust-rfcbot added proposed-final-comment-period An FCP proposal has started, but not yet signed off. disposition-merge FCP with intent to merge labels Aug 28, 2026

weihanglo moved this to FCP merge in Cargo status tracker Sep 1, 2026

weihanglo added this to Cargo status tracker Sep 1, 2026

rust-rfcbot added final-comment-period FCP — a period for last comments before action is taken and removed proposed-final-comment-period An FCP proposal has started, but not yet signed off. labels Sep 1, 2026

Uh oh!

Uh oh!

Conversation

gmemuriuki commented Aug 24, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What does this PR try to resolve?

How to test and review this PR?

Test covers

The following tests were run:

Uh oh!

rustbot commented Aug 24, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

weihanglo Aug 24, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

weihanglo Aug 24, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gmemuriuki Aug 24, 2026

Choose a reason for hiding this comment

Uh oh!

weihanglo commented Aug 24, 2026

Uh oh!

epage commented Aug 25, 2026

Uh oh!

gmemuriuki commented Aug 25, 2026

Uh oh!

weihanglo commented Aug 26, 2026

Uh oh!

gmemuriuki commented Aug 26, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

rustbot commented Aug 27, 2026

Uh oh!

weihanglo left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

epage commented Aug 28, 2026

Uh oh!

rust-rfcbot commented Aug 28, 2026 • edited by 0xPoe Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

weihanglo commented Aug 28, 2026

Uh oh!

arlosi commented Sep 1, 2026

Uh oh!

rust-rfcbot commented Sep 1, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

gmemuriuki commented Aug 24, 2026 •

edited by rustbot

Loading

weihanglo Aug 24, 2026 •

edited by rustbot

Loading

weihanglo Aug 24, 2026 •

edited by rustbot

Loading

weihanglo left a comment •

edited by rustbot

Loading

rust-rfcbot commented Aug 28, 2026 •

edited by 0xPoe

Loading