If it was intended for local configuration I’d expect it to be part of .cargo/config instead.
(yes, this is a thing! Wild how rarely anybody ever mentions it, right? I never even knew it existed until last month)
Sorry, it appears you may be right! They go over the intended usage scenarios in the Specifying Dependencies guide.
The desire to override a dependency or otherwise alter some dependencies can arise through a number of scenarios. Most of them, however, boil down to the ability to work with a crate before it’s been published to crates.io. For example:
- A crate you’re working on is also used in a much larger application you’re working on, and you’d like to test a bug fix to the library inside of the larger application.
- An upstream crate you don’t work on has a new feature or a bug fix on the master branch of its git repository which you’d like to test out.
- You’re about to publish a new major version of your crate, but you’d like to do integration testing across an entire project to ensure the new major version works.
- You’ve submitted a fix to an upstream crate for a bug you found, but you’d like to immediately have your application start depending on the fixed version of the crate to avoid blocking on the bug fix getting merged.
These scenarios are currently all solved with the
[patch] manifest section.
(…although… the last bullet point does sound similar to your use case. At least, in all the ways that should affect how the feature works in cargo)