I know there's a section about overriding-dependencies, but it would be more convenient if one can directly modify the source code after IDE has already jumped to the target crate. AFAIK golang has this support, it's very convenient for debugging IMO.
UPDATE
The current behavior is: I can edit and save the target crate code directly in the IDE, but the changes are not picked up by rustc.
What you are editing is the user global cargo cache, which cargo expects to never change. Any changes to dependencies have to be done through the [patch] section in Cargo.toml to replace them with a local copy which you can edit.
Yeah, but it would be much more convenient if cargo can pick up the changes directly. At least there should be an option to enable such behavior even if not enabled by default IMO.
You need to manually cargo clean the specific package, otherwise Cargo assumes that it is not modified, to speed up no-ops builds significantly.
But there are also plans to make crate checkouts directory read only, which seems like a pretty good idea.
I wonder if there’s already a custom cargo sub command which sets up the relevant patch section and local checkout automatically?
I mean cargo can be made more clever than this, tool should bring as much convenience to users as possible, right?
The problem with editing the dependency cache is that it is user local so it doesn't apply to other users of your project and applies to all projects you compile. As such you can easily end up breaking other projects and prevent others from being able to compile your own project. Using a [patch] section you can put the patched crate directly in your project such that other users can build with the patched version and projects of others aren't affected by the changes.
You can make Cargo more clever in this case, but this also would significantly reduce performance of a no-op build. Noticing that something's changed in local copies of crates.io crates requires a lot of disk io.
Let's make sure that we're on the same page, by "dependency cache" we're referring to the ~/.cargo/registry/src directory, right?(This is where my IDE jumps to). About the breaking issue, it should be easy to deal with if the entire directory is managed by git, in that case it would be easy to revert all changes.
Is there anyone else that feels the [patch] way is not convenient enough? It's too much work if one just want to add some println.
I think the global cache being immutable is fine. If anything, the IDE should properly prevent you from editing it, because such changes can't be used anyway. Perhaps the IDE could suggest automatically vendoring a changed dependency?
On the other hand, it would be nice if there were a simple command, which would vendor a dependency locally. cargo vendor, unfortunately, pulls the whole dependency tree rather than a single crate. Probably someone already made a subcommand like that, I just don't know about it.
I made cargo dl a while ago for downloading crates locally, but it doesn’t have any integration for choosing the version based on the lockfile or injecting it in as a patch. I might be tempted to add support for that if it’s trivial though 
.
And I got around to prototyping this as part of cargo dl: https://github.com/Nemo157/cargo-dl/tree/patch
> ls
Cargo.lock Cargo.toml src/
> cat Cargo.toml
[package]
name = "foo"
version = "0.1.0"
edition = "2021"
[dependencies]
syn = "2.0.18"
> cargo dl --patch syn
workspace metadata parsed
crates.io index updated
syn extracted syn 2.0.18 to syn-2.0.18
Cargo.toml patched
> ls
Cargo.lock Cargo.toml src/ syn-2.0.18/
> cat Cargo.toml
[package]
name = "foo"
version = "0.1.0"
edition = "2021"
[dependencies]
syn = "2.0.18"
[patch.crates-io]
syn = { path = "syn-2.0.18" }
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.