These are chat archives for trueaccord/ScalaPB

12th
Jun 2018
Andrea Peruffo
@andreaTP
Jun 12 2018 07:55
it is not strictly blocking as a subproject of ScalaPB, but it prevent from other extensions ... what I expect is to have several runtime/generators for grpc runtime (e.g. Node, Grpc-web, Akka-streams ...) and I don't think keeping all implementations in ScalaPB repo is a good solution ...
Gary Coady
@fiadliel
Jun 12 2018 11:56
Btw I wrote an implementation that extends scalapb’s grpc generation, but uses cats-effect/FS2 instead.
The project is here, if anybody is interested: https://github.com/fiadliel/fs2-grpc
@thesamet I found that sbt plugin for scalapb was hard to extend, because many ideas/settings were not exposed as SBT settings or tasks; my plugin exposes some of these, which then in turn calls scalapb appropriately. Would you be interested in a PR to push some of this into your plugin?
Andrea Peruffo
@andreaTP
Jun 12 2018 12:03
@fiadliel thanks for sharing!
Nadav Samet
@thesamet
Jun 12 2018 15:50

@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 asFs2GrpcPlugin). 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 libraryDepenency to project/build.sbt and the users can add fs2Grpc to their PB.targets.

Nadav Samet
@thesamet
Jun 12 2018 15:57
I like the case object interface 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 directly.
(let me know if I'm missing anything though)
@andreaTP yes, separate repo makes sense. Can you prepare a small repo that would demonstrate the problem you are having with the compiler plugin? Try using the one that is not shaded, and if necessary provide your own shaded compiler plugin
Gary Coady
@fiadliel
Jun 12 2018 16:06
@thesamet the generator options come from 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.
for (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.
indeed, it’s just the lack of visibility over arguments to gen()that forced the wrapping.
Gary Coady
@fiadliel
Jun 12 2018 16:14
I can certainly do a PR for the case object stuff - the CodeGeneratorOption trait and associated support, right?
Nadav Samet
@thesamet
Jun 12 2018 18:02
@fiadliel Yes, PR would be welcome for CodeGeneratorOption if it makes things easier downstream. We can even have an overloaded version of scalapb.gen that 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...