There's no way for one bzlmod module to share a @crates hub with another. Every module that uses the crate extension must declare its own from_cargo, and each from_cargo builds an independent hub. So a crate two modules both depend on (e.g. log) becomes two distinct Bazel targets → two rlibs in the same binary. For any crate with global/static state, that breaks the shared-state assumption: log's logger, tracing's dispatcher, cross-crate type identity / Any, etc.
Concretely: a repo with a git submodule wired in via bazel_dep + local_path_override (both real modules in one graph) where the submodule ships a log bridge and the parent emits through log. Each module gets its own @crates//:log, so the logger installed by one is invisible to the other.
(Note: rules_rust doesn't support this either but think that it should).
I have an ai assisted workaround which treats a module that uses the crate extension but declares no from_cargo as a consumer of a hub another module already built. That way a crate like log resolves to one shared target across the module graph, is this repo open to such a solution? Do you have other ideas of how it might be solved?
There's no way for one bzlmod module to share a
@crateshub with another. Every module that uses thecrateextension must declare its ownfrom_cargo, and eachfrom_cargobuilds an independent hub. So a crate two modules both depend on (e.g.log) becomes two distinct Bazel targets → two rlibs in the same binary. For any crate with global/staticstate, that breaks the shared-state assumption:log's logger,tracing's dispatcher, cross-crate type identity /Any, etc.Concretely: a repo with a git submodule wired in via
bazel_dep+local_path_override(both real modules in one graph) where the submodule ships alogbridge and the parent emits throughlog. Each module gets its own@crates//:log, so the logger installed by one is invisible to the other.(Note:
rules_rustdoesn't support this either but think that it should).I have an ai assisted workaround which treats a module that uses the crate extension but declares no
from_cargoas a consumer of a hub another module already built. That way a crate like log resolves to one shared target across the module graph, is this repo open to such a solution? Do you have other ideas of how it might be solved?