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

[epage]

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

• --lockfile-path: which this feature started its life as, see RFE: add option to specify path to Cargo.lock #5707
  • Allow to set lockfile-path via an environment variable #15510 has a use case for this also to be done via an env variable (pain on user to always specify the flag)
  • A dedicated CLI flag doesn't feel like it carries its own weight (see also Is --out-dir justified or can we find another way of accomplishing it? #6100)
  • A config field more obvious semantics ("change the default") vs a flag which questions like "should cargo install --lockfile-path foo imply --locked?"

See also

• Summary of the original cargo team discussion: RFE: add option to specify path to Cargo.lock #5707 (comment)
• Discussion for changing to env variable Allow to set lockfile-path via an environment variable #15510 (comment)

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?

[rustbot]

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]

@rfcbot fcp merge cargo

[rust-rfcbot]

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

• @0xPoe
• @Eh2406
• @Muscraft
• @arlosi
• @ehuss
• @epage
• @joshtriplett
• @weihanglo

Concerns:

• install resolved by feat(config): Stabilize resolver.lockfile-path config #16694 (comment)

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.

[epage]

@rfcbot fcp concern install

Inconsistency in resolver table being applied to cargo install

Should we remove install support or have this inconsistent?

[0xPoe]

Thanks!

The changes look good.

View changes since this review

[0xPoe]

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.

[weihanglo]

Should we remove install support or have this inconsistent?

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

[weihanglo]

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]

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.

[epage]

@rfcbot fcp resolved install

#16823 removed support from cargo install.

[epage]

@weihanglo

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.

Is this now resolved with resolver.lockfile-path not applying to cargo install?

I would also add that there is little reason to set this globally. This is more intended for local config, env variables, and CLI.

[epage]

@ehuss I expanded the PR description

[weihanglo]

Thanks for helping resolve that!

@rust-rfcbot reviewed

[rust-rfcbot]

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

[rust-rfcbot]

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]

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]

Thanks!