Autoreload with patch."ssh://git@..."

[apetrovic-indata]

I have a directory with several repos under development, N lib repos an M bin repos that use the lib repos. In order to cover my development, there is a sibling .cargo directory with config.toml that declares patches for all the development repos.
The patches are in the form of

[patch."ssh://git@myforgejo/my_lib"]
my_lib = { path = "/workspace/my-lib" }

Now, when rust analyzer starts working, the ssh urls will get updated (Updating git repository ssh://git@...), this obviously touches the repos (I'm not exactly sure which files, but I suspect it's the Cargo.toml) and Autoreload gets triggered. This brings rust analyzer to an infinite loop.
Currently, the only remedy to the infinite loop I'm aware of is to disable Autoreload.
But, with Autoreload disabled, any change I make in any repo of mine triggers a warning
Auto-reloading is disabled and the workspace has changed, a manual workspace reload is required.
and rust analyzer stops being a reliable helper in my development.

Is there a more elegant approach to get rust analyzer out of the infinite Autoreload loop with ssh url patches?

[ShoyuVanilla]

Sorry for the late reply. I'll check what's happening

[ChayimFriedman2]

What do you expect rust-analyzer to do? Is there a way to not got into an infinite loop? rust-analyzer just calls Cargo, that updates the repository, and it also watches over changes and reruns Cargo.

We could probably avoid that if we will compare the old and new contents and don't rerun Cargo if nothing has changed, but that will degrade performance for everyone else, which I don't think is justified. Your working method seems like a bad practice.

[ChayimFriedman2]

A workspace? Patches are shared inside a workspace.

[apetrovic-indata]

Some of the N lib repos are workspaces already. If I were about to create a devel-only workspace for all N lib repos and M bin repos (with many of the repos already being workspaces themselves), could that work, and how?

It seems that my approach to some massive cross-repo development is off, no wonder I'm already changing my approach during the last weeks. Workspace seems to be the hierarchically highest unit of development. On the other hand, from what I've experienced as a newbie to Rust, I don't need patches within a workspace, everything is neatly linked locally within.

So, .cargo/config.toml patches are not to be used with Rust Analyzer?

[apetrovic-indata]

The more I think of it, the more I'm clear that's what rust-analyzer is supposed to do: compare the old contents with the new. Otherwise, the statement "it also watches over changes" is not true, right? touch-ing a Cargo.toml shouldn't trigger rust-analyzer?
On the other hand, to what extent will the performance be degraded if rust-analyzer starts watching over changes? Even more RAM usage?

[ChayimFriedman2]

Memory usage won't be impacted, speed will, and in latency-sensitive parts of r-a. We also don't have a good way to compare the speed, and I wouldn't want to take the risk.

So, .cargo/config.toml patches are not to be used with Rust Analyzer?

They can be used just fine, just not in the way you do it.