Added rust_prost_transform rule for modifying granular proto_library

[UebelAndre]

This new rule is to support granular modifications to existing proto_library targets without adding duplicate actions to the build graph depending on what rust_prost_library target was consumed.

closes #2045

[illicitonion]

This seems really handy!

The placement on the proto_library is interesting compared to other languages... It feels like in other languages, each proto_library would have a lang_proto_library target wrapping it, and that that would be an obvious place to put this data. Whereas we don't expect one prost_proto_library per proto_library but instead glom together a bunch of proto_library targets into one prost_proto_library, which means any attributes on that are a bit disconnected from the .proto files they're applying to...

I'd be slightly tempted to say we should add this as a dict[ProtoLabel, TransformLabel] to prost_proto_library rather than adding it to the proto_library itself (using data for this feels... Convenient, but wrong?)

But also, at the end of the day this seems useful and fine, so... Feel free to merge, but would be interested in your thoughts...

[UebelAndre]

I'd be slightly tempted to say we should add this as a dict[ProtoLabel, TransformLabel] to prost_proto_library rather than adding it to the proto_library itself (using data for this feels... Convenient, but wrong?)

We discussed this offline but for posterity, the way the rules work is by using an aspect to perform the protogen and rustc compile on the proro_library targets themselves to try and avoid issues around duplicate symbols. I know of no way to have the rule inject data to the aspect action. The only way I could think of was to add such a mapping to the toolchain but that seemed untenable. Thus I've come up with this idea which is primarily intended for devs to add additional prost info to their proto_library targets (external will be harder to modify).

I think this is something that would be easy to phase out if a better solution comes along but I haven't seen one yet. Pull-requests welcome!

[samschlegel]

I know of no way to have the rule inject data to the aspect action.

You should be able to just use ctx.attr here as demonstrated in the Aspects intro docs. Adding stuff to the data this way shouldn't be required, and there should be other ways to get around the duplicate symbols such as using the name of the aspect rule as the crate name instead of the proto_library?

[UebelAndre]

I know of no way to have the rule inject data to the aspect action.

You should be able to just use ctx.attr here as demonstrated in the Aspects intro docs. Adding stuff to the data this way shouldn't be required, and there should be other ways to get around the duplicate symbols such as using the name of the aspect rule as the crate name instead of the proto_library?

I’m happy to take a look at other pull requests that can provide the same functionality in a cleaner way 😄