fix(bazel): un-scope crate_universe extension so @crates resolves downstream - #75
Merged
Merged
Conversation
…nstream `snmalloc-rs/BUILD.bazel`'s `:snmalloc_rs_profiling` target depends on `@crates//:flate2` unconditionally. The crate_universe extension that materialises that repo was declared `dev_dependency = True`, but Bazel skips dev_dependencies of non-root modules, so consumers of the fork analyze-fail with: No repository visible as '@crates' from repository '@@snmalloc+' Drop the dev scoping so `@crates` is visible to any module that pulls the fork. The flate2-free `:snmalloc_rs_profile_compat` target stays in place for downstream consumers that do not need `write_pprof_gz`; this fix only matters for the `:snmalloc_rs_profiling` path. Companion to capitalintent/konfig CU-86aj23u16 (heap-profile.pprof endpoint shipped against a locally-patched fork pin via `git_override(patches=...)`); after this lands, konfig drops the patch and bumps the pin.
jayakasadev
added a commit
that referenced
this pull request
Jun 16, 2026
…76) PR #75 dropped `dev_dependency = True` so downstream consumers could resolve `@crates//:flate2` referenced by `:snmalloc_rs_profiling`. That fixed the visibility problem but introduced a worse one: any consumer that also calls `use_extension("@rules_rust//crate_universe:extension.bzl", "crate")` under the default repo name `crates` collides with this module and bzlmod refuses to evaluate: Defined two crate universes with the same name in different MODULE.bazel files (`crates`). Switch the materialised repo name to `snmalloc_crates` via `crate.from_specs(name = ...)` and alias it back to `@crates` inside this module's namespace via `use_repo(crate, crates = "snmalloc_crates")`. Result: * `snmalloc-rs/BUILD.bazel`'s `@crates//:flate2` ref still resolves (alias is module-local). * Downstream modules' own `@crates` repo is untouched — they only see `@snmalloc_crates` if they explicitly use_repo it. The `isolate = True` alternative was attempted first but is still gated behind `--experimental_isolated_extension_usages`; renaming is the stable path on Bazel 9.x.
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
2 participants
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.
What
dev_dependency = Truefrom the@rules_rust//crate_universe:extension.bzlextension declaration inMODULE.bazel.Why
snmalloc-rs/BUILD.bazel's:snmalloc_rs_profilingtarget references@crates//:flate2unconditionally. Bazel skipsdev_dependencydeclarations of non-root modules, so any downstream Bazel consumer that depends on:snmalloc_rs_profilingfails analysis with:The flate2-free
:snmalloc_rs_profile_compattarget (added in #74) stays available for consumers that do not needwrite_pprof_gz; this fix only matters for the full-profiling path.Cost
flate2(transitively) materialised in the consumer's resolved module graph whenever the snmalloc fork is pulled. The crate is feature-gated to:snmalloc_rs_profilingonly, so consumers depending solely on:snmalloc_rsor:snmalloc_rs_profile_compatsee no link-time impact.Evidence
git_override(patches=...)flipping this same flag, withbazel build //rust/konfig:konfig_bin_heapprof+bazel test //rust/konfig:test_heapprofPASS locally. With this fix landed the patch is removed.