Allow Cargo patches without modifying `Cargo.lock`

[coffeeispower]

Problem

I maintain a monorepo containing several Rust projects as subtrees. During development, I use [patch] entries to make those projects compile against local versions of shared dependencies. The same patches are also needed when building the system with Nix.

This works for compilation, but Cargo writes patch information into Cargo.lock. That creates unwanted changes from normal editor activity, including rust-analyzer or even just from running cargo normally, and makes the lockfile describe the local development setup instead of the dependency declared by the package, which adds unwanted changes in git and makes the packages impossible to be compiled separately without modifying the lock file all the time.

For example, a dependency declared from crates.io or GitHub should continue to point to that source in Cargo.lock, even when a local path patch is used during development. Unused patch entries should not be added either.

Proposed Solution

Add a boolean configuration option:

[resolver]
write-patches-to-lockfile = false

When disabled, Cargo should:

• Continue applying patches during dependency resolution and compilation.
• Avoid writing [[patch.unused]] entries.
• Ignore existing [[patch.unused]] entries when reading the lockfile.
• Preserve the original dependency source in Cargo.lock, including crates.io or GitHub sources.
• Preserve the existing lockfile contents when applying a patch does not otherwise change the dependency graph.

The default should remain true for compatibility with current Cargo behavior.

Notes

I have vibecoded an ad-hoc patch to borrow myself some time to develop the main project while this feature is not in standard cargo. It's available at https://github.com/ardos-os/cargo/tree/codex/lockfile-patch-sources
If you're fine upstreaming that exact code I can submit a pull request or if you want to change something in the implementation, i'm available to make those adjustments.

[weihanglo]

Thanks for the issue report!

Are your patches from disjoint Cargo workspaces? I wonder if this is a duplicate of #15130.

[coffeeispower]

@weihanglo it's related but my issue is actually broader than that because it's not just removing patch.unused, it's actually making the lock file be generated like there's no patch at all, all dependencies still point to their original locations with their original hashes

[coffeeispower]

This is because I still want each subproject to be able to built separately outside of the workspace. If I use normal cargo workspaces, if you try to build the package outside of the monorepo, it won't work because it points to relative paths that don't exist. So instead each package points to the github repository of that package and inside the monorepo, it has patches to make them point to the local versions of each package so changes reflect immediately everywhere.

[epage]

A big challenge in how to frame such a feature is that patches can change dependency resolution. Cargo does not know if the lockfile changed because of a patch or another reason.

In a way, this reminds me of the "resolve dependencies on a read-only filesystem" issue. There we worked around it by allowning users to point to an alternative lockfile location. For those users, thats fine. Here, it may be cumbersome but could be helped by creating a cargo wrapper.

[weihanglo]

There we worked around it by allowning users to point to an alternative lockfile location.

FWIW, the configuration for this: resolver.lockfile-path.

[coffeeispower]

@epage that doesn't solve the issue that existing dependencies in the lock file must keep their versions. A cargo wrapper like that creates a split brain problem + requires setting up your environment in a special way so you don't have to type the path of the wrapper everytime + doesn't integrate well with rust analyzer. For people that use a lot of git dependencies like me it's very important

[coffeeispower]

Not saying this is the only way to achieve that, cargo could instead provide a feature specifically for the usecase i'm describing, where you have independent crates and workspaces you want to develop together without coupling them to the local filesystem