These are chat archives for trueaccord/ScalaPB
@fiadliel Thanks for sharing. I'm still not following what's the use case of extending the SBT plugin or providing another SBT plugin (such as
Fs2GrpcPlugin). Wouldn't it be sufficient to provide the code generator as a library, along with a helper function
fs2Grpc that returns
JvmGenerator("scala-fs2-grpc", Fs2CodeGenerator), scalapbCodeGeneratorOptions.value.filterNot(_ == CodeGeneratorOption.Fs2Grpc).map(_.toString)), (sourceManaged in Compile).value / "fs2-grpc" )
Then this library can be added as a
project/build.sbt and the users can add
fs2Grpc to their
case objectinterface for ScalaPB (so a PR would be welcome), but I'm not sure the reason for automatically instantitating the generator for the user with certain settings from another plugin - there's always going to be someone who wants to remove it or add it with some other settings, so the docs can just suggest to the user to use
scalapb.gen()(arguments to a scala function call), and are not visible to another plugin - I want to use same arguments, without requiring user to specify arguments twice.
(sourceManaged in Compile), I think that where the code goes has a very reasonable default, so don’t want to make user specify this every time. But this is more my personal taste in SBT plugin design.
gen()that forced the wrapping.
case objectstuff - the
CodeGeneratorOptiontrait and associated support, right?
scalapb.genthat take a
Seq[CodeGeneratorOption]. Note that ScalaPB internally uses something called
GeneratorParams(https://github.com/scalapb/ScalaPB/blob/493985f6db305b48c0bf29fdea4ca813a8835bd8/compiler-plugin/src/main/scala/scalapb/compiler/ProtobufGenerator.scala#L11) which has some overlap with this. This may or may not be relevant to this PR...