Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Please document proto_library providers #3527

Closed
jmillikin-stripe opened this issue Aug 9, 2017 · 7 comments
Closed

Please document proto_library providers #3527

jmillikin-stripe opened this issue Aug 9, 2017 · 7 comments
Assignees
Labels
P3 We're not considering working on this, but happy to review a PR. (No assignee) type: documentation (cleanup)

Comments

@jmillikin-stripe
Copy link
Contributor

From reading the source it seems there exist Skylark providers for proto_library targets ( ProtoSourcesProvider and ProtoSupportDataProvider), but the documentation on built-in providers (https://docs.bazel.build/versions/master/skylark/lib/skylark-provider.html) doesn't mention them. Please document these providers.

Even a brief overview such as https://docs.bazel.build/versions/master/skylark/lib/JavaSkylarkApiProvider.html would be very useful.

@hlopko hlopko added P3 We're not considering working on this, but happy to review a PR. (No assignee) type: documentation (cleanup) category: rules > misc native labels Aug 9, 2017
@djudd-stripe
Copy link

Maybe relatedly, it doesn't appear possible to return these providers from a custom rule. To specify that a rule accepts proto_library inputs, you can write providers=["proto"], but Bazel does not accept "proto" as a valid return type from a rule implementation. If there's a way to make this work as-is, it would be useful to document it; if not, it would be a nice feature, to support plugging custom-generated file descriptor sets into the native ecosystem.

@cgrushko cgrushko assigned lberki and unassigned cgrushko Dec 2, 2017
@cgrushko
Copy link
Contributor

cgrushko commented Dec 2, 2017

@djudd-stripe for this to work, we need to expose ProtoSourceProvider [1] to Skylark. I haven't done something like this, but in general it means adding a function to a top-level Skylark module. It's straightforward but we never got around to doing this.

This will allow you to write a custom proto_library rule - what's your use case?

[1] - https://github.com/bazelbuild/bazel/blob/b3da717469e23f5293297175a80709956416fd2c/src/main/java/com/google/devtools/build/lib/rules/proto/ProtoSourcesProvider.java

@djudd-stripe
Copy link

Thanks for the response!

We've written custom proto_library-equivalent rules to get features like those requested in https://github.com/bazelbuild/bazel/issues/4201 and #3867

Another use case involves tooling for passing schema definitions between repos. Our implementation involves uploading proto descriptor sets to a shared blob store in a build step, and then downloading them for import at build time elsewhere. Often the import uses Bazel, and it would be nice to be able to use those descriptor sets like native proto_libraries without assuming the exporting repo also uses Bazel. The current workaround here is to turn the descriptor sets back to .proto files using the C++ library's DebugString in a repository rule, but that's fairly awkward (especially because it requires pre-preparing a compiled binary unless/until #4069 is implemented).

@djudd-stripe
Copy link

I'd be happy to take on implementing this sometime in the next few weeks, but might need some support.

@cgrushko
Copy link
Contributor

cgrushko commented Dec 2, 2017

@brandjon for help in exposing provider instantiation to Skylark.

@djudd-stripe
Copy link

It turns out that there's already a ticket that actually covers the ask I made in the comment here: #3701

@jmillikin-stripe
Copy link
Contributor Author

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P3 We're not considering working on this, but happy to review a PR. (No assignee) type: documentation (cleanup)
Projects
None yet
Development

No branches or pull requests

5 participants