Repository navigation
Tracking Issue for -Zlockfile-path #14421
Description
Summary
Original issue: #5707
Implementation: #14326
Documentation: https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#lockfile-path
The -Zlockfile-path flag enables the resolver.lockfile-path configuration option,
which allows you to specify the path of the lockfile Cargo.lock.
Unresolved Issues
- Inconsistency in
resolvertable being applied tocargo install - How this should work if the lockfile or a parent directory is not present
- In #14326, missing parent directories will be created when Cargo is about to write the lockfile. This minimizes the chance of creating dangling directories.
-
cargo install --lockfile-path=<path>implies--locked, and requires the alternative lockfile to exist.- This behavior diverges from other commands, which allow the absence of lockfile at the alternative path.
- Allow to set
lockfile-pathvia an environment variable #15510
Future Extensions
No response
Tasks
- Add an unstable doc under https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#lockfile-path doc: add lockfile-path unstable doc section #14423
-
cargo installshould make--lockfile-pathimply--lockedfeat: lockfile path implies --locked on cargo install #14556 - Add support for
resolver.lockfile-pathin fix(lockfile): switch toresolver.lockfile-pathconfig #16510 - Expand
resolver.lockfile-pathcoverage in fix(lockfile-path): Respect the config in fix, install #16617 - Remove
--lockfile-pathin 1.95.0-nightly
About tracking issues
Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Metadata
Metadata
Assignees
Labels
Type
Projects
- Status
Activity
ifropc commentedon Aug 18, 2024
@rustbot claim
Auto merge of #14424 - Ifropc:lockfile-tracking-issue, r=weihanglo
Auto merge of #14423 - Ifropc:lockfile-doc, r=weihanglo
ifropc commentedon Sep 27, 2024
As far as shell completions go, I don't think we need to do anything in the scope of this task. In fact, it's alreadyready working on the latest nightly (as part of #14520)
epage commentedon Sep 27, 2024
@ifropc thats the new, unstable completion system.
The task is referring to our handwritten, stable completions
epage commentedon Sep 27, 2024
That said, you could add a custom completer to the new completion system that restricts completions to files named
Cargo.lockusingPathCompleter::file().filter(...), see https://docs.rs/clap_complete/latest/clap_complete/engine/struct.PathCompleter.htmlAuto merge of #14556 - Ifropc:lockfile-path-install, r=weihanglo
ifropc commentedon Sep 27, 2024
Got it, I will add the support into the stable system + will do the lock filter in the new system. Thought the unstable stuff is automatically grouped into the unstable autocomplete system as well, but guess it's a separate matter.
Thanks Ed!
cargo run/build(and possibly other commands) should have the option to ignore the lockfile (likecargo installdoes):--unlocked#15827 as a duplicate of this issue[-]Tracking Issue for `--lockfile-path`[/-][+]Tracking Issue for `-Zlockfile-path`[/+]epage commentedon Jan 15, 2026
#16510 changed this from a CLI flag to a config field. See also #15510
fix(lockfile): switch to `resolver.lockfile-path` config (#16510)
fix(cli): Remove `--lockfile-path`
fix(cli): Remove `--lockfile-path`
fix(cli): Remove `--lockfile-path`
fix(cli): Remove `--lockfile-path` (#16621)
feat(config): Stabilize `resolver.lockfile-path` config (#16694)
ifropc commentedon Apr 17, 2026
Great job team!!