Allow runtime_deps to be specified for kt_jvm_proto_library #505
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
A common use case we run into is producing the Kotlin proto library for a proto file A that depends on one or more proto files B. In such a case we would like to produce the Kotlin proto library for both A and B so we can use the Kotlin DSL to build both A and its nested fields of type B. However, the
kt_jvm_proto_librarymacro does not have a way to express this quasi-dependency relationship. For example we have:We're not able to have users of the
a_kt_prototarget to automatically pull inb_kt_proto. We can work around this by addingb_protodirectly as a dep ofa_kt_protoso that both are compiled together. But this is less than ideal because, we may also have ac_protothat also depend onb_proto. If we putb_protoas a direct dependency of botha_kt_protoandc_kt_proto, the same file is compiled twice, and later on when we assemble a Jar combininga_kt_protoandc_kt_protowe get a conflict.Of course
a_kt_protodoes not really depend onb_kt_proto, so everything still compiles and works. But users would expect to be able to use the Kotlin DSL to build all parts of thea.protomessages, including the parts that are fromb.proto. And we do not want users to go hunt for all transitive dependencies ofa.prototo find the correspondingkt_jvm_proto_librarytargets and assemble the dependency graph themselves. I think the runtime_deps concept appropriately captures the relationship between the twokt_jvm_proto_librarytargets, and we can accomplish the transitive dependency pulling by simply addingb_kt_protoas a runtime_dep ofa_kt_proto. This PR adds rumtime_deps to thekt_jvm_proto_libraryto support this use case