Allow to set lockfile-path via an environment variable

[tnull]

Problem

In #14326, the capability to specify an lockfile-path was added to cargo. It would be awesome if this would also possible to configure via an environment variable, similar to CARGO_TARGET_DIR.

Proposed Solution

Add the capability to set the lockfile path via a CARGO_LOCKFILE_PATH environment variable.

Notes

See also #14421

[epage]

Could you describe your use case?

[tnull]

Could you describe your use case?

Sure! I'd like to be able to mount the Rust project directory read-only into a container environment (e.g., docker,podman) for security reasons. To this end, I'd love to use lockfile-path to avoid having to modify the project directory.

This however currently would require me to append --lockfile-path to each invocation of cargo build/cargo test, which is fine for manually-run commands, but there are also a bunch of CI scripts that I'd need to patch each time the container is set up to consider the lockfile-path argument. Instead, it would be really handy to be able to set CARGO_LOCKFILE_PATH once globally, which is what I already do for CARGO_TARGET_DIR.

(Btw, it seems I'm not alone in this: https://users.rust-lang.org/t/specifying-the-location-of-the-cargo-lock-file/8977/5 describes exactly my use-case, essentially)

[weihanglo]

Out of curiosity, why do you generate Cargo.lock on the fly, instead of checking it in the version control system?

[tnull]

Out of curiosity, why do you generate Cargo.lock on the fly, instead of checking it in the version control system?

For one, the projects this is referring to are all libraries, where we still adhere to the (by now somewhat relaxed) guidance to not check-in Cargo.lock. We also run cargo update as part of our CI to pin/unpin certain package versions, depending on whether we're testing under MSRV or not.

[epage]

I can see having the lockfile-path more easily reused between multiple commands. As this flag is not expected to be commonly used, I wonder if we should remove --lockfile-path in favor of the config.

I think I would name the config resolver.lockfile-path (CARGO_RESOLVER_LOCKFILE_PATH). See also [resolver].

If this is put in the config, I wonder if we should support variable substitution like build-dir so its easier to set this once for all packages that make be interacted with when in this mode of operation.