Dmitri Polchinski

> Hey, thanks for the contribution! There's one problem with this implementation: the named directive keys syntax. As per SIP-46, directives have to be clean, simple pairings of key strings...

> As for the listed known issues: > > > Execution order for multiple generators is undefined > > I think this can be addressed in a subsequent PR, for...

> Should we use special extensions for source generators? Something like `script.sourcegen.scala` and then `//> using sourcegen script` when we want to use it? > > We could define everything...

I also think we should add an out-of-box support for popular generators like ScalaPB. For example, with this line in project.scala: ```scala //> using sourcegen scalapb ``` This directive would:...

> Hm... 2 options I see here. > > * `script.sourcegen.scala` (or `script.sourcegen.sc`?) is a script which itself runs the source generator, in which case any Scala code in there...

> Something along this lines, what do you think? I'm a bit confused, I thought the idea was to rely on bloop to execute the command and track its inputs/outputs.

> That is the idea, sure. I was thinking of compiling the script first and then providing it to Bloop as a jar to run. This would basically be just...

Are there any pros/cons of defining the command as a class instead of a directive? ```scala // In protobuf.sourcegen.scala //> using sourceGenerator.input file.proto //> using sourceGenerator.output Generated.scala //> using sourceGenerator.glob...

> This becomes a DSL, which we want to avoid (and I think we can't actually do formally). There is no other command currently that does it. Isn't `${.}` also...

> For existing ones it makes it a bit tougher, but we can release a bunch even ourselves together with Scala CLI. But any new ones will be quite easy...