Ability to change a crate in the whole dependency graph?

In some situations, there is a basic crate which provides fundamental functionalities, and several downstream crates depending on this basic crate. For example, log is the basic crate, and env_logger or some other logger implementations are downstream crates. We want to modify the basic crate (without any breaking change) locally, and test the downstream crates. For now, we have no choice but to clone all downstream crates, and only modify its Cargo.toml to point the dependency to local path.

This situation is very common in scientific research, where we do fundamental optimizations for some basic crates, and we want all downstream crates could be benefited.

Is there any RFC talking about this? I thought it may be related to the public-private-dependencies, but I couldn't find the concrete discusssions about this situation.

See Overriding Dependencies - The Cargo Book

Thank you for your reply! I previously knew this feature, but maybe I have some misunderstanding. Let's say our crate A depends on crate B and C, and C depends on B (and the version resolution unify them to a single B version). We want to patch B, so will the [patch] section in crate A's Cargo.toml affect the dependency of crate C?

Yes, [patch] will affect the whole dependency tree. If you only wanted to change the local dependency, you would just modify that directly, no need for a patch mechanism.

2 Likes

Thank you! This solves my problem.

Note that [patch] entries are supported in cargo configuration files, too, which could be useful for testing multiple dependent crates independently without rewriting even a single Cargo.toml for each test case.

You can even pass configuration options through environment variables or command line options, so overriding a dependency on a built is probably even possible without modification of any file on disk.

3 Likes