Patches in ~/.cargo/config.toml add [[patch.unused]] to Cargo.lock #15130

Activity

1. epage

   added

   A-configurationArea: cargo config files and env varsArea: cargo config files and env vars

   A-patchArea: [patch] table overrideArea: [patch] table override

   S-triageStatus: This issue is waiting on initial triage.Status: This issue is waiting on initial triage.

   on Feb 3, 2025
2. epage commented on Feb 3, 2025

   

   epage

   on Feb 3, 2025

   Contributor

   More actions

   Could you provide more context for your use case? For your cargo install command, do you need the patch? If so, why? Do you need --locked and, if so, why?

   What I'm wanting to weigh is the impact and scope of this. In that linked comment, the alternative was to not support the feature at all.
3. epage

   added

   S-needs-infoStatus: Needs more info, such as a reproduction or more background for a feature request.Status: Needs more info, such as a reproduction or more background for a feature request.

   and removed

   S-triageStatus: This issue is waiting on initial triage.Status: This issue is waiting on initial triage.

   on Feb 11, 2025
4. epage commented on Apr 28, 2025

   

   epage

   on Apr 28, 2025

   Contributor

   More actions

   Forgot to add, why is the patch being put in ~/.cargo/config.toml rather than in a location specific to your repo?
5. epage

   added

   Command-install

   I-nominated-to-discussTo be discussed during issue triage on the next Cargo team meetingTo be discussed during issue triage on the next Cargo team meeting

   on Apr 28, 2025
6. ehuss

   added this to Cargo status trackeron Apr 29, 2025
7. ehuss

   moved this to Nominated in Cargo status trackeron Apr 29, 2025
8. epage

   removed

   I-nominated-to-discussTo be discussed during issue triage on the next Cargo team meetingTo be discussed during issue triage on the next Cargo team meeting

   on Apr 29, 2025
9. weihanglo commented on Jan 11, 2026

   

   weihanglo

   on Jan 11, 2026

   Member

   More actions

   I was wondering a resolver.track-unused-patches = false or something else to stop writing [[patch.unused]] to lockfile?

   While rust-analyzer fixes the issue rust-lang/rust-analyzer#19667 by using --lockfile-path, I still feel like this approach is better:

   • Using --lockfile-path may create a completely new lockfile when no lockfile pre-exists. Stoping tracking unused patches won't.

   • While Alex said

     Resolving a dependency graph is intended to be a project-local decision, not a global system-configuration decision. That's sort of what Cargo has always trended towards.

     dependency solving gradually becomes a configurable feature. If one has system-wide patches (for example, my scenario unused [patch] in $CARGO_HOME/config.toml failed loading sysroot metadata rust-analyzer#19667 (comment)), a way to turn of that is useful.
10. epage commented on Jan 12, 2026

    

    epage

    on Jan 12, 2026

    Contributor

    More actions

    @weihanglo you spoke to your use case in rust-lang/rust-analyzer#19667, could you carry it forward to here? Currently this is "needs info" as we need more use case information from the existing requester.

    Using --lockfile-path may create a completely new lockfile when no lockfile pre-exists. Stoping tracking unused patches won't.

    Isn' that up to how people implement things? They can copy over the lockfile and then use it.
11. weihanglo commented on Jan 12, 2026

    

    weihanglo

    on Jan 12, 2026

    Last edited by epage

    Member

    More actions

    Commented by weihanglo in rust-lang/rust-analyzer#19667 (comment)

    why is it that you have a patch in your user config?

    The tool I am building leverages [patch] in config for overriding a dependency with a local copy shared between “Cargo workspaces”. You can see it as the tool one level above which interacts and manages multiple Cargo workspaces. The tool use CARGO_HOME to achieve that as @arielb1 has described.

    However, the lockfile in every package doesn't care about whether the actual lockfile content is changing. But loading metadata for std workspace is an outlier because

    • it passes --locked

    • we don't really want to fetch std's dependencies or re-resolve std.

    Commented by epage in rust-lang/rust-analyzer#19667 (comment)

    To summarize some clarifications I got from @weihanglo: When there are unused patches, a section gets added to all Cargo.lock files that are affected. Where unexpected, this could be problematic. When asking how this is dealt with, the answer is basically

    • They do their own locking for their internal projects so Cargo.lock is ignored

    • This is a special CARGO_HOME setup just for internal projects by their build tool so this does not negatively affect other projects that do care about their Cargo.lock

    Now, looking back on when .cargo/config.tomls [patch] table was under discussion, Alex was concerned about the negative impact on global config (source). Jon had said this was for project-local config and not global config (source). Unsure if the custom CARGO_HOME didn't exist yet or if how it was being used was "local" in Jon's mind but I think there was a disconnect here and we are now dealing with the after affects of that. Alex even expressed concern over "misuse" of this feature (source) and my feeling is that we are in that territory.

    Personally, I'd rather we not develop a one-off solution for what feels like an extreme corner case. I feel like we should evaluate unused patches in CARGO_HOME on a case-by-case basis to evaluate what the intended workflow should be. Take #15130 for example. Our options include

    • Have the user patch the source and install that

    • Create an install-only config and special handle its unused patches

    • Find a general solution to unused patches in the user config
12. weihanglo commented on Jan 12, 2026

    

    weihanglo

    on Jan 12, 2026

    Member

    More actions

    Using --lockfile-path may create a completely new lockfile when no lockfile pre-exists. Stoping tracking unused patches won't.

    Isn' that up to how people implement things? They can copy over the lockfile and then use it.

    Yeah but in rust-lang/rust-analyzer#19667 (comment):

    The annoyance with --lockfile-path is the need for us to allocate a temp dir / file though :/

    Minor annoyance unless the projects are those that can only work on readonly filesystem (which we should fix through #10096 but having a escape hatch here help a bit).