Add standalone protoc plugin binaries#23736
Closed
srikrsna-buf wants to merge 2 commits into
Closed
Conversation
Signed-off-by: Sri Krishna <[email protected]>
Signed-off-by: Sri Krishna <[email protected]>
srikrsna-buf
requested review from
JasonLunn,
dmaclach,
haberman,
jskeet and
zhangskz
and removed request for
a team
October 1, 2025 14:14
jskeet
removed their request for review
October 1, 2025 14:30
Contributor
|
Superseded by #23919 |
copybara-service Bot
pushed a commit
that referenced
this pull request
May 18, 2026
Follow-up to #23736 and #13308 but with only Bazel targets added per feedback. This PR adds targets to build protoc plugins for all the built-in plugins. This will result in the following binaries being available: - protoc-gen-cpp - protoc-gen-csharp - protoc-gen-java - protoc-gen-kotlin - protoc-gen-objectivec - protoc-gen-php - protoc-gen-python - protoc-gen-pyi - protoc-gen-ruby - protoc-gen-rust Closes #23919 COPYBARA_INTEGRATE_REVIEW=#23919 from bufdev:standalone-plugins 45d44f6 PiperOrigin-RevId: 917373434
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.
Reviving #13308.
Most of the changes are similar, except for the rust and cpp targets. They were already in main.
This PR adds targets to build protoc plugins for all the built-in plugins. This will result in the following binaries being available:
protoc-gen-cpp
protoc-gen-csharp
protoc-gen-java
protoc-gen-kotlin
protoc-gen-objectivec
protoc-gen-php
protoc-gen-python
protoc-gen-pyi
protoc-gen-ruby
protoc-gen-rust
The goal of this PR is for these to be added as assets to each GitHub release, although we are unable to find the code that builds the assets for releases - if it is in this repository, let us know and we're happy to do any work required!
There's multiple motivations for this PR:
Optimally, people want to version their plugins separately from their compiler. That is, the version of protoc should be decoupled from the version of each plugin, as is the case with the rest of the Protobuf ecosystem outside of the built-in plugins. You should be able to, for example, take advantage of fixes in protoc v24.0 whilst continuing to use the Java generated code from v23.0, in case there are breaking changes you're unable to adopt yet.
This partially addresses #5587 - the core motivation behind this issue is that when piping a FileDescriptorSet into protoc with --descriptor_set_in, and then invoking one of the built-in plugins, different code can result, as the value for json_name will be subtly different when taking an external FileDescriptorSet vs protoc producing one internally and then invoking one of the built-in plugins.
Selfishly, it makes life a lot easier for alternative Protobuf compilers. For example, for us with buf, to use the built-in plugins, we have a convoluted mechanism to proxy to protoc that cannot deal with issue #5587, and requires people to install both protoc and buf when they may just want one of the built-in plugins. Having separate, independently-versionable plugins would make our lives a lot easier.
The majority of this PR is something we have already been maintaining for our remote plugins feature within Buf, we're just hoping we can get this upstreamed, as we think it would benefit the Protobuf community.
Follow-ups that would be nice:
Adding to GitHub releases, as mentioned.
Get these plugins installed as part of the Homebrew protobuf formula. There's precedent for this with i.e. the grpc formula, which installs each language-specific plugin.
Change protoc to default to using an on-disk plugin vs a built-in plugin, that is if protoc-gen-cpp exists, use protoc-gen-cpp over the builtin cpp plugin. This allows people to independently version plugins as mentioned, and mirrors the behavior of the Well-Known Types (if a WKT is in the include path, it is used instead of the WKTs included as part of the protoc distribution). We're happy to put up a PR for this as well.