feat: coalesce crates into one linked lib where possible across hubs/features/versions - #255
Draft
genevieve-me wants to merge 4 commits into
Draft
Conversation
Move resolution and generated repository rendering into a private module, leaving tag declarations and orchestration in the public extension. Preserve behavior and update Starlark library dependencies.
Share schema-qualified registry and Git fact keys between downloading and resolution. Include Git checkout and member-layout inputs, and stage sparse metadata under source-qualified paths. Regenerate facts with Bazel 9.0.0 and add cache-key regression coverage.
Attach source-qualified logical identity to registry and Git libraries and proc macros, leaving binaries and build scripts untagged. Pin the public rules_rust revision providing optional identity metadata and verify provider propagation with analysis tests.
identity, compatibility, deterministic ordering, finalization, and core regressions
genevieve-me
force-pushed
the
feat/crate-coalescence-cross-hub
branch
from
September 8, 2026 23:10
bd488b3 to
6414a90
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Resolves #144. Depends on hermeticbuild/rules_rust#57. Hefty MR so I tried to break it into individually reviewable commits: a lot of the lines changed number is churn in Bazel lockfiles.
This change allows one Bzlmod module to share a
@crateshub with another module without producing duplicate Rust libraries for the same Cargo package. When the same compatible Cargo package appears in multiple hubs,rules_rsnow reuses a single generated library target. If two configured instances are not safe to link into the same binary, the build fails during analysis instead of quietly linking both copies.Each hub records the compilation properties that affect whether two crate instances can safely be shared, and those records are combined before assigning compatible instances to a canonical generated target. If the information needed to establish compatibility is missing, that combination is rejected.
I tested this to cover compatibility edge cases like optional-dependency and feature interactions that can change the effective crate graph, e.g.,
dep?/featureinteractions and dependencies whose presence or configuration depends on enabled features.The MR split up metadata and archive handling so that crates with the same name and version from different registries can coexist correctly - I figured some users might have an internal registry with a foobar 1.0.0 that collides with crates.io foobar 1.0.0.
This will need a rules_rust dependency bump once identity is in that ruleset.
Behavior notes
Dependency processing now uses deterministic topological ordering, so coalescing gives the same result regardless of input ordering. Repository staging and generated names are deterministic, with explicit collision detection.
This does not introduce global Cargo dependency resolution. Each hub still owns its own lockfile and dependency closure; coalescing only determines when compatible crate instances from those independent hubs may safely share a generated library target.
Package identity from rules_rust includes the package source as well as its name and version. In the future, we could use full Cargo Package IDs instead of name and version, since right now crates with the same name and version but different sources are rejected.
The current compatibility-class construction is intentionally conservative and fails closed when link safety cannot be established.