Dependency on `scalapb.options.ScalapbProto` in generated code.
Closed this issue · 3 comments
When I customize the generation using file-level options, the generated file looks something like this:
...
object GreeterProto extends _root_.scalapb.GeneratedFileObject {
lazy val dependencies: Seq[_root_.scalapb.GeneratedFileObject] = Seq(
scalapb.options.ScalapbProto
)
...
i.e. we have scala code depending on the scalapb.options.ScalapbProto
class even if we never use it. That means that code that uses generated classes has to depend on scalapb options even it it doesn't care.
Expected behavior is no dependencies scalapb.options.ScalapbProto
in the generated code so the usage of options is transparent to the client code.
I confirm the behavior you are describing: the dependencies
field corresponds to the list of imports. There is no pruning for whether the imported file is being actually referenced in the proto, and there's no special behavior for ScalapbProto
. This behavior matchesthe official java protobuf API.
I want to understand what problem this is actually causing in your project. Can you clarify or provide an example how "code that uses generated classes has to depend on scalapb options even it it doesn't care"?
I wasn't happy that is depends on scalapb-runtime
but now I see the generated code depends on it anyway so no problem. Thank you.
Right, scalapb-runtime provides functionality needed for the generated code to work, including base classes and traits for the generated code.