Feature Request: Add Starlark method to create a ProtoInfo provider

[cheister]

Description of the problem / feature request:

Currently the only way to create a ProtoInfo provider in Starlark is to use the native proto_library rule to generate one. This limitation means you cannot implement a proto_library rule in Starlark that works with the native proto rules.

Feature requests: what underlying problem are you trying to solve with this feature?`

The main issue this helps workaround is #10744 where we want to create a proto_libary rule with sources that come from an external jar. This may not make sense to add to the native proto_library rule so we wrote our own rule to implement it instead.

The second issue is rewriting the native proto_library rule in Starlark #10005. If we can create a ProtoInfo provider in Starlark we can write a Starlark proto_library rule that will support the "sandwich" interoperability principle with the native proto rules.

My proposed API mentioned in the discussion of #10966 for the proto_common method is

proto_info = create_proto_info(
  proto_source_root,
  descriptor_set,
  sources,
  deps,
  exports
)

Which only exposes parts of protoInfo that directly correspond to arguments that are passed to protoc.

[Yannic]

(If possible: block on #10939 which changes some internals of ProtoInfo)

Do I understand correctly that this is merely going to be a constructor for ProtoInfo (i.e. the caller is responsible for creating the descriptor set)?

[cheister]

Ok, I'll try rebasing on #10939 and see what's different.

But yes, this is just a constructor that lets Starlark rules create ProtoInfo objects as if they were a Provider declared in Starlark. So the rule will have to create the descriptor set as a file and pass it as an argument.

[TimoPtr]

@cheister any update on your suggestion? I see that in BazelProtoCommon protoInfo is annotated with StarlarkMethod but I didn't find any way to use it in starlark

[github-actions]

Thank you for contributing to the Bazel repository! This issue has been marked as stale since it has not had any activity in the last 1+ years. It will be closed in the next 90 days unless any other activity occurs or one of the following labels is added: "not stale", "awaiting-bazeler". Please reach out to the triage team (@bazelbuild/triage) if you think this issue is still relevant or you are interested in getting the issue resolved.

[Yannic]

Still a useful feature

[github-actions]

Thank you for contributing to the Bazel repository! This issue has been marked as stale since it has not had any activity in the last 1+ years. It will be closed in the next 90 days unless any other activity occurs. If you think this issue is still relevant and should stay open, please post any comment here and the issue will no longer be marked as stale.

[github-actions]

This issue has been automatically closed due to inactivity. If you're still interested in pursuing this, please post @bazelbuild/triage in a comment here and we'll take a look. Thanks!