Repository navigation
fix: support aggregator proto_library deps and put generated code on the load path - #424
Open
pwhite-mongo wants to merge 1 commit into
Open
pwhite-mongo wants to merge 1 commit into
pwhite-mongo wants to merge 1 commit into
Conversation
pwhite-mongo
force-pushed
the
fix/proto-aggregators-and-load-paths
branch
from
October 14, 2026 18:18
a8ddba8 to
f2a89a6
Compare
…the load path
The Ruby proto aspect indexed the first generated file unconditionally, so
analysis failed on proto_library targets that only bundle other protos via
`deps` (e.g. `@envoy_api//:v3_protos`):
Error: index out of range (index is 0, but sequence has 0 elements)
Such targets now generate nothing and forward their deps' Ruby files.
Generated `_pb.rb` files require each other relative to their proto import
root, but only the runfiles root was on RUBYLIB, so protos from external
repositories (and stripped/virtual import prefixes) could not be required.
RubyFilesInfo gains `transitive_load_paths`, which the aspect populates with
each output root and rb_binary/rb_test prepend to RUBYLIB. This removes the
need for the manual $LOAD_PATH setup in examples/proto.
Protos from @protobuf are skipped so the well-known types come from the
google-protobuf gem rather than generated copies shadowing it.
The proto example CI job now runs tests instead of only building the app.
pwhite-mongo
force-pushed
the
fix/proto-aggregators-and-load-paths
branch
from
October 14, 2026 18:24
f2a89a6 to
8fda41b
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
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.
disclaimer: This is robot code. I experienced the problem described below, fidgeted with settings I didn't understand for a couple hours, and then finally found the issue. Being only marginally useful with either bazel or ruby, I caved to pressure and told claude
chase down the error I get from bazel build :blahblah. I have checked it myself, for whatever that's worth, and am willing to stake my reputation on the output. Claude's message is below:The Ruby proto aspect indexed the first generated file unconditionally, so analysis failed on proto_library targets that only bundle other protos via
deps(e.g.@envoy_api//:v3_protos):Such targets now generate nothing and forward their deps' Ruby files.
Generated
_pb.rbfiles require each other relative to their proto import root, but only the runfiles root was on RUBYLIB, so protos from external repositories (and stripped/virtual import prefixes) could not be required. RubyFilesInfo gainstransitive_load_paths, which the aspect populates with each output root and rb_binary/rb_test prepend to RUBYLIB. This removes the need for the manual $LOAD_PATH setup in examples/proto.Protos from @protobuf are skipped so the well-known types come from the google-protobuf gem rather than generated copies shadowing it.
The proto example CI job now runs tests instead of only building the app.