Extended proto rule

[purkhusid]

What?

Adds a new rule for compiling protobuf to scala. This rule is not aspect based and that allows the user to add extra dependencies to the compilation.

Why?

The current proto rule does not support adding extra dependencies becaue it's aspect based.

How?

Extracted some of the functionality of the aspect based rule and reused it in the new rule.

[purkhusid]

This is my first draft of this rule. I just wanted to see if there was interest in getting it into rules_scala.

[simuons]

@purkhusid have you tried this rule on your code base? I'm wondering how many other requirements would pop up. I think with this rule you would need to replicate whole proto_library hierarchy with scala_proto_library_extended as in your example https://github.com/bazelbuild/rules_scala/issues/751#issuecomment-698903655 I would suggest to have that rule locally and try it on your codebase. This would reveal all your requirements. In my opinion this might be a good addition but also a heavy one. In a sense that there would be two distinct ways how to generate scala from proto.

[purkhusid]

@purkhusid have you tried this rule on your code base? I'm wondering how many other requirements would pop up. I think with this rule you would need to replicate whole proto_library hierarchy with scala_proto_library_extended as in your example #751 (comment) I would suggest to have that rule locally and try it on your codebase. This would reveal all your requirements. In my opinion this might be a good addition but also a heavy one. In a sense that there would be two distinct ways how to generate scala from proto.

@simuons Yeah, I'll try it out in my codebase first and see what pops up. There is one thing that I would like to fix but I'm unable to figure it out, how do I only pass top level dependencies to the compilation? E.g. in the test I created in this PR the custom_import_libtarget is pulled transitively to the proto2_test compilation. Any pointers on how to to limit the transitive dependencies in the compilation?

[simuons]

Any pointers on how to to limit the transitive dependencies in the compilation?

I think this is the place where all transitive deps gets merged https://github.com/bazelbuild/rules_scala/pull/1114/files#diff-65fac07922564e63374c6db4871ef5dcR44

[ittaiz]

I agree with @simuons in general that this is a heavy addition that should be done only if it's applicable to enough use cases (and definitely only after you see it fully helps your use case). Additionally the direction of having different strategies for messages and services (like java) makes a lot of sense.

[ianoc]

I do really like the separation of the services out from the message generation (we have extra/special services generation stuff similar to wix, finagle based services services, and then also some other ones for doing http 1 requests where needed).

I think those transitive deps in the compilation bit fwiw (though I don't know if its needed/should go away in general since the aspect should be aware of the direct deps I believe), but those aren't the issue of the old rules I'm pretty sure -- those are jar dependencies rather than the old problem is multiple sets of sources. (difference here is that jar dependencies won't get merged into the output jar, where as a source dependency would be in the output jar)

[liucijus]

closing as stale, feel free to reopen