Workspace with lots of independent crates not handled in an ideal way

[sdroege]

The workspace in question is https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/ . There are lots of independent crates collected in there and the workspace Cargo.toml is only provided to have

• shared workspace dependencies so updates only have to happen in a single place
• shared build profile
• a way to build everything at once
• sharing build results of common dependencies

The way how rust-analyzer handles workspaces, this becomes an obstacle during development.

• By default rust-analyzer builds the whole workspace and not just the default members (rust-analyzer.check.workspace)
  • Some crates have external C dependencies that cargo does not know about so the build would fail for those even if they're not of interest right now
  • Disabling rust-analyzer.check.workspace causes them to not be built, but even when working on those crates they wouldn't be built (this seems to be a general problem with non-default cargo features too)
• Usually one works only on a single crate at a time but building everything takes quite some time and system resources
  • For just running cargo this can be worked around by simply running it from a terminal inside the subdirectory of interest, but rust-analyzer does not seem to provide any such behaviour

Do you have any suggestions how this can be improved, either by changes in rust-analyzer, configuration changes (as rust-analyzer configuration is global and not per repository this would seem problematic), or re-organization of the layout of the repository?

[Veykril]

Is this strictly about r-a running cargo check for diagnostics? Or is the build script step it does already a problem? There isn't really a way to limit rust-analyzer what to packages to consider in a cargo workspace, and I don't really want to add something like that. r-a works on cargo workspaces and what cargo metadata reports as a workspace is what we use, which in this case will always be the top level virtual one.

Disabling rust-analyzer.check.workspace causes them to not be built, but even when working on those crates they wouldn't be built (this seems to be a general problem with non-default cargo features too)

Is this wouldn't a typo? (accidental negation) Otherwise I am somewhat confused by the problem here as disabling the workspace flag should suffice then

[sdroege]

the build script step it does already a problem

The build script step would fail in some cases, but even if they all pass there would still be the problem that r-a would cargo check all the crates.

There isn't really a way to limit rust-analyzer what to packages to consider in a cargo workspace, and I don't really want to add something like that

Do you have a suggestion how to organize such a collection of crates differently so that rust-analyzer behaves better while still being able to declare dependency versions in a single place and share build results?

Is this wouldn't a typo? (accidental negation)

Yeah that happens often :) But not here. The problem with disabling rust-analyzer.check.workspace is that then these non-default members of the workspace are not built (good, partially solves the original problem), but they also wouldn't be built when editing files of these crates (bad, a new problem). So depending on what you're working on you would have to switch configuration back and forth.

And the parenthesis there is about the related problem to that (but not exactly the same): if you have a crate with non-default features and you edit code that is disabled with the default features then r-a would not check that code. You'd have to temporarily change the default features in the Cargo.toml (for example) to get the desired behaviour.

[Veykril]

Do you have a suggestion how to organize such a collection of crates differently so that rust-analyzer behaves better while still being able to declare dependency versions in a single place and share build results?

No unfortunately there isn't really a way to do that

Regarding the check behavior if I understand this right:
We'd want to add a third flycheck "state", currently we have workspace (aka --workspace) and effectively crate (the edited crate), what you seem to want here is "crate and its (transitive) dependents"? Which I think should be a good addition, but requires some restructuring of the flycheck infra (I wonder if cargo would be interested in having this itself 🤔).

Regarding the features stuff, does using the cargo.features config not suffice?

[sdroege]

"crate and its (transitive) dependents"

That sounds correct, yes :)

does using the cargo.features config not suffice

It's a global configuration and you'd have to change it back and forth whenever changing projects. Or maybe other editors allow per "project" r-a configurations (coc.nvim in neovim here)?

[Veykril]

I see, well we have landed rudimentary rust-analyzer.toml support now which allows one to have per project configuration (its not really documented yet). So that might help. I hope to document that this or next week

Or maybe other editors allow per "project" r-a configurations (coc.nvim in neovim here)?

VScode does, others I don't know.