-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFE: add option to specify path to Cargo.lock #5707
Comments
@alexcrichton any idea how the option could be named? I'm thinking about making a patch. |
Perhaps |
We talked about this in the Cargo team meeting and are open to people experimenting with this
|
@rustbot claim |
@epage sorry it took me some time, but the PR is ready for review. |
@Ifropc No worry. As |
Add `--lockfile-path` flag This change implements a new `--lockfile-path` proposed in #5707 . Functionality added: - Add `--lockfile-path <PATH>` to all commands that support `manifest-path` with exception of: - `locate-project` (doesn't use lock file) - `verify-project` (is deprecated) - `read-manifest` (doesn't use lock file) - Behind -Zunstable-options and docs - The flag's docs / `--help` has (unstable) in them - `<PATH>` must end with `Cargo.lock`. If specified path doesn't exist (or parent director(ies), create all the parent directories and the lockfile itself Implementation TLDR: add `requested_lockfile_path` into `Workspace` and set it on `workspace(gctx)` call (setting from the context) Update `lockfile.lock_root()` to respect `requested_lockfile_path` (if set) Add test cases covering all affected commands. Tested creating lockfile, reading lockfile, overriding default (`./Cargo.lock`) lockfile, symlink tests. Extra tests for package to make sure pinned versions from path's lockfile are respected (i.e. double check correct lockfile is used) I doubt this flag will be used for any command that's not read-only, but I tried to cover all the commands.
Most major tasks in #5707 (comment) were addressed via #14326. Below are remaining tasks:
Open questions before stabilization
|
Personally, I wouldn't make a checkbox for that. That is enough of an open question that it should be carried forward to stabilization with a call out of what was chosen for the implementation.
We should not be blocking completion work on that effort. We'll likely have that start as a nightly-only opt-in so we can do acceptance testing on it. |
Thanks for your reviews! I will do the follow ups for |
I believe the intent was to call out the potential for it being throwaway work which it would be if it was close to being merged and stabilized. However, we do not know how close we are to stabilization until we merge and do a couple rounds of call-for-testing, so any completion work that is pending should still be done. |
Close in favor of the tracking issue #14421 |
In Fedora we package all crate sources (including tests) in
/usr/share/cargo/registry
which is not user-writable. However, we would like to run tests for them after installation. There is already option fortarget-dir
and it would be very nice to get option to put Cargo.lock in some other directory so that we could runcargo test
from there.The text was updated successfully, but these errors were encountered: