RFE: add option to specify path to Cargo.lock #5707

Activity

1. alexcrichton

   added

   C-feature-requestCategory: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted`Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted`

   on Jul 11, 2018
2. igor-raits commented on Jul 11, 2018

   

   igor-raits

   on Jul 11, 2018

   ContributorAuthor

   More actions

   @alexcrichton any idea how the option could be named? I'm thinking about making a patch.
3. alexcrichton commented on Jul 12, 2018

   

   alexcrichton

   on Jul 12, 2018

   Member

   More actions

   Perhaps --lockfile-path to mirror --manifest-path?
4. ehuss

   added

   A-lockfileArea: Cargo.lock issuesArea: Cargo.lock issues

   on Apr 6, 2020
5. weihanglo

   added

   S-needs-designStatus: Needs someone to work further on the design for the feature or fix. NOT YET accepted.Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted.

   on May 10, 2023
6. epage

   added

   S-acceptedStatus: Issue or feature is accepted, and has a team member available to help mentor or reviewStatus: Issue or feature is accepted, and has a team member available to help mentor or review

   and removed

   S-needs-designStatus: Needs someone to work further on the design for the feature or fix. NOT YET accepted.Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted.

   on Jul 16, 2024
7. epage commented on Jul 16, 2024

   

   epage

   on Jul 16, 2024

   Last edited by epage

   Contributor

   More actions

   We talked about this in the Cargo team meeting and are open to people experimenting with this

   • CLI flag only, no config, no manifest support
   • Name: --lockfile-path <path>
   • Behind -Zunstable-options and docs
     • The flag's docs / --help should have (unstable) in them
   • Looks like it belongs on all commands that take --manifest-path except cargo locate-project
   • cargo install should make --lockfile-path imply --locked
   • Must require the file_name be Cargo.lock (like we do for --manifest-path). We can always re-evaluate this in the future
   • Main question is how this should work if the lockfile or a parent directory is not present
     • I would lean towards "create them" rather than "error"

   👍React with 👍1Reacted by Weihang Lo

   ❤️React with ❤️1Reacted by ifropc
8. ifropc commented on Jul 16, 2024

   

   ifropc

   on Jul 16, 2024

   Contributor

   More actions

   @rustbot claim
9. rustbot

   assigned

   ifropc

   on Jul 16, 2024
10. ifropc commented on Jul 31, 2024

    

    ifropc

    on Jul 31, 2024

    Contributor

    More actions

    @epage sorry it took me some time, but the PR is ready for review.
    I followed the guideline you posted in your comment (thank you very much!)
    1 slight difference is I haven't added --lockfile-path on cargo install yet, as it's not one of the command that takes the --manifest-path.
    I think the main usage of the lockfile-path is to enable folks to run commands on readonly folders (and adding it to almost all --manifest-path commands for consistency is a good idea). However, cargo install doesn't really fit into this category, so I doubt there's going to be any demand for that.
    That being sad, adding it is very easy (and to be completely honest I just completely missed your suggestion up until I opened the PR), so if you think it'd be a nice addition it's not a problem to add it to the set of supported commands.

    ❤️React with ❤️1Reacted by Weihang Lo
11. weihanglo commented on Jul 31, 2024

    

    weihanglo

    on Jul 31, 2024

    Member

    More actions

    @ifropc No worry. As --lockfile-path is not going to be insta-stable, that seems fine to me. We can always discuss use cases later.

    👍React with 👍1Reacted by ifropc
12. bors

    added a commit that references this issue on Aug 16, 2024

    Auto merge of #14326 - Ifropc:5707-lock-path, r=weihanglo

    ...

    3293d22
13. weihanglo commented on Aug 16, 2024

    

    weihanglo

    on Aug 16, 2024

    Last edited by weihanglo

    Member

    More actions

    Most major tasks in #5707 (comment) were addressed via #14326. Below are remaining tasks:

    • cargo install should make --lockfile-path imply --locked
      • #14326 didn't add --lockfile-path to cargo-install. This should be addressed before stabilization.
    • Shell completions.
      • May have conflicts with the GSoC shell completion project.
    • Feature gate tests. Lockfile path tests (follow-up) #14417
      • We forgot to add those tests in #14326.

    Open questions before stabilization

    • 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.
14. epage commented on Aug 16, 2024

    

    epage

    on Aug 16, 2024

    Contributor

    More actions

    Main question is how this should work if the lockfile or a parent directory is not present

    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.

    May have conflicts with the GSoC shell completion project.

    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.

    👍React with 👍1Reacted by Weihang Lo
15. ifropc commented on Aug 16, 2024

    

    ifropc

    on Aug 16, 2024

    Last edited by ifropc

    Contributor

    More actions

    Thanks for your reviews! I will do the follow ups for cargo install (sorry actually just forgot about it 😅 ) and tests in separate PRs.
    As for GSoC shell completion, from my understanding it's an ongoing effort, as of now. I don't see why would it be conflicting with the new flag, but if any help needed I would be happy to be involved!
16. epage commented on Aug 16, 2024

    

    epage

    on Aug 16, 2024

    Contributor

    More actions

    As for GSoC shell completion, from my understanding it's an ongoing effort, as of now. I don't see why would it be conflicting with the new flag, but if any help needed I would be happy to be involved!

    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.

    👍React with 👍2Reacted by Weihang Lo and ifropc
17. weihanglo

    linked a pull request that will close this issueLockfile path tests (follow-up) #14417on Aug 18, 2024
18. weihanglo commented on Aug 18, 2024

    

    weihanglo

    on Aug 18, 2024

    Member

    More actions

    Close in favor of the tracking issue #14421

    ❤️React with ❤️1Reacted by ifropc
19. weihanglo

    closed this as completedon Aug 18, 2024
20. github-merge-queue

    added a commit that references this issue on Apr 17, 2026

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

    ...

    da06c61