Skip to content

feat(config): Stabilize resolver.lockfile-path config - #16694

Merged
weihanglo merged 1 commit into
rust-lang:masterfrom
epage:lockfile-path
Apr 17, 2026
Merged

feat(config): Stabilize resolver.lockfile-path config#16694
weihanglo merged 1 commit into
rust-lang:masterfrom
epage:lockfile-path

Conversation

@epage

@epage epage commented Mar 3, 2026 •
edited by rustbot
Loading

Copy link
Copy Markdown
Contributor

View all comments

What does this PR try to resolve?

Closes #14421

Overall, this seems like a low policy knob for users to tweak in config (ie out of the way) so this seems relatively safe to stabilize.

resolver.lockfile-path is a mechanism to override the default location for lockfiles for local development

  • The filename must be specified and must be Cargo.lock
  • Making a decision about template support generally, and which variables more specifically, was deferred out
    • { and } are reserved to keep this a two-way door
  • Besides changing the location, all other lockfile behavior remains the same, e.g. automatic creation of the lockfile, automatic parent directory creation, how --locked works'
  • this remains consistent with config behavior
    • like resolver.incompatible-rust-version, resolver.lockfile-path does not apply to cargo install
    • like other paths in config, paths are relative to .cargos parent directory if .cargo/config.toml is used and the current working directory for env variables and CLI.

This started out as a principled workaround to no or outdated lockfiles on read-only filesystems. This could also help with users who juggle multiple lockfiles (e.g. "latest" vs "msrv") particularly when they can have dedicated config files for the different lockfiles and override other relevant resolver settings in the same config file.

Alternatives

See also

Unresolved questions from the tracking issue:

Inconsistency in resolver table being applied to cargo install

cargo install --lockfile-path=<path> implies --locked, and requires the alternative lockfile to exist.

cargo install no longer respects resolver.lockfile-path so we remain consistent on [resolver] never applying to cargo install.

How this should work if the lockfile or a parent directory is not present

This was from when the we had --lockfile-path instead which added its own set of policy questions.
By having this be a config that just overrides the default, all other policies should remain the same.

How to test and review this PR?

@epage epage added the T-cargo Team: Cargo label Mar 3, 2026
@rustbot rustbot added A-documenting-cargo-itself Area: Cargo's documentation A-unstable Area: nightly unstable support A-workspaces Area: workspaces S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 3, 2026
@rustbot

rustbot commented Mar 3, 2026

Copy link
Copy Markdown
Collaborator

r? @ehuss

rustbot has assigned @ehuss.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

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

@epage

epage commented Mar 3, 2026

Copy link
Copy Markdown
Contributor Author

@rfcbot fcp merge cargo

@rust-rfcbot

rust-rfcbot commented Mar 3, 2026 •
edited by Muscraft
Loading

Copy link
Copy Markdown
Collaborator

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

Concerns:

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.

@rust-rfcbot 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 Mar 3, 2026
@epage

epage commented Mar 3, 2026

Copy link
Copy Markdown
Contributor Author

@rfcbot fcp concern install

Inconsistency in resolver table being applied to cargo install

Should we remove install support or have this inconsistent?

0xPoe
0xPoe approved these changes Mar 3, 2026
View reviewed changes

@0xPoe 0xPoe left a comment •
edited
Loading

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! :shipit:

The changes look good.

View changes since this review

@0xPoe

0xPoe commented Mar 3, 2026

Copy link
Copy Markdown
Member

Should we remove install support or have this inconsistent?

In which cases would we need to specify the lockfile path and install binaries? This configuration is primarily for using read-only source directories. I couldn't wrap my head around coming up with a use case for it.

@rustbot

This comment has been minimized.

Sign in to view
@epage epage mentioned this pull request Mar 4, 2026
Merged
@weihanglo

weihanglo commented Mar 5, 2026

Copy link
Copy Markdown
Member

Should we remove install support or have this inconsistent?

Just remind that we also have an inconsistency of install not respecting [patch] #12855.

@weihanglo

weihanglo commented Mar 5, 2026

Copy link
Copy Markdown
Member

Do we think the support of unsetting the lockfile path a blocker? Currently there is no way to do that. And without that, it is hard for people to unset if a global resolver.lockfile-path is applied to cargo-install.

@ehuss

ehuss commented Mar 6, 2026

Copy link
Copy Markdown
Contributor

I'm not quite clear which inconsistency we're talking about.

  • That cargo install requires --locked to honor resolver.lockfile-path?
  • That cargo install with --locked and resolver.lockfile-path doesn't honor other settings in the resolver table?
  • Something else?

Also, is there a more detailed description of this feature? Overall I'd like to see a more detailed stabilization report. For example, it seems to reserve {} substitutions, but I don't see that mentioned anywhere. There also seems to be various small details, like it seems to create intermediate directories (which is good). Is the path relative to the workspace root? The current directory? The consideration of an config value versus CLI flag was captured out in #15510 (comment). Things like that would help in understanding what is being proposed here.

@ehuss ehuss moved this to FCP blocked in Cargo status tracker Mar 8, 2026
@epage
epage marked this pull request as draft March 10, 2026 14:02
@rustbot rustbot removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Mar 10, 2026
@weihanglo weihanglo mentioned this pull request Apr 2, 2026
Merged
@rustbot

This comment has been minimized.

Sign in to view
@rustbot rustbot added the S-waiting-on-author Status: The marked PR is awaiting some action (such as code changes) from the PR author. label Apr 2, 2026
@epage

epage commented Apr 2, 2026

Copy link
Copy Markdown
Contributor Author

@rfcbot fcp resolved install

#16823 removed support from cargo install.

@rustbot

This comment has been minimized.

Sign in to view
@rust-rfcbot rust-rfcbot added finished-final-comment-period FCP complete to-announce and removed final-comment-period FCP — a period for last comments before action is taken labels Apr 17, 2026
@rust-rfcbot

rust-rfcbot commented Apr 17, 2026

Copy link
Copy Markdown
Collaborator

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

@rustbot

rustbot commented Apr 17, 2026

Copy link
Copy Markdown
Collaborator

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.

@weihanglo

weihanglo commented Apr 17, 2026

Copy link
Copy Markdown
Member

Thanks!

@weihanglo
weihanglo enabled auto-merge April 17, 2026 20:34
@weihanglo
weihanglo added this pull request to the merge queue Apr 17, 2026
Merged via the queue into rust-lang:master with commit da06c61 Apr 17, 2026
29 checks passed
@rustbot rustbot removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Apr 17, 2026
@weihanglo weihanglo mentioned this pull request Apr 18, 2026
Merged
rust-bors Bot pushed a commit to rust-lang/rust that referenced this pull request Apr 18, 2026
@bors
Auto merge of #155470 - weihanglo:update-cargo, r=weihanglo
cb7913a 
Update cargo submodule

26 commits in eb94155a9a60943bd7b1cb04abec42f5d0de6ddc..3bf1388b8823ec4eab622340036593381d8871aa
2026-04-09 13:10:20 +0000 to 2026-04-17 23:27:26 +0000
- Add global HTTP timeout tracking to http_async (rust-lang/cargo#16903)
- feat(config): Stabilize `resolver.lockfile-path` config (rust-lang/cargo#16694)
- chore(deps): update msrv (1 version) to v1.95 (rust-lang/cargo#16897)
- fix: rebuild rustdoc json for different versions of a same crate (rust-lang/cargo#16773)
- Add effective_url to http_async (rust-lang/cargo#16899)
- Make crate downloads process as a queue rather than a stack (rust-lang/cargo#16898)
- fix: sparse registry fetch progress reporting (rust-lang/cargo#16900)
- chore: bump to 0.98.0; update changelog (rust-lang/cargo#16892)
- docs(semver-check): update diagnostics to Rust 1.95 (rust-lang/cargo#16895)
- docs(ref): Better highlight 'package --list' for include/exclude (