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