Am I correct that mu only respects the
package option (and requires it) when generating server/client definitions from
.proto files? Some of the
proto files I'm dealing with have package names that I don't want to use when generating Scala code and some have no package names at all.
I could've manually provided the target directory for generation that points to the package I want (which would only work assuming that all generated classes should reside in the same package), but that will still fail if there is no package name in the
.proto file - I always have to provide it.
I really want to keep the original package names in the
.proto definitions, because that's important when communicating with other teams, so is there a way I could "customize" the target package without having to modify the
packageoption when generating server/client definitions from
.protofiles. We do have an option for customizing the target directory (to an extent) that can be configured in your
build.sbt(or similar) called
muSrcGenIdlTargetDir(more details can be found here: https://higherkindness.io/mu-scala/reference/source-generation). This plugin setting determines the name of the target directory to write your generated protobuf code into (the default being target/scala-2.13/src_managed/main/), so I think it would be possible to use that plugin to specify different target directories for your generated protobuf code if you don't want to modify the package names. That said, I don't know if this is a complete answer to your question, and I'm happy to help you further if you can provide more specific details to what you're trying to do :)
@dmarticus thank you for the response, really appreciate it! Basically confirms all my assumptions. Though I really love Mu, this may be the reason why we'd have to switch to ScalaPB as it allows to be very flexible when generating packages.
Is it likely that in the future
skeuomorph and, by extension,
mu will support options like
scalaplugin for gradle will work with this library (https://guides.gradle.org/building-scala-libraries/). Not sure if you've tried that approach already; please let me know if you did and you're getting errors
.use(client => ...)?
Right now I initiate resource at a top level and then pass the client down into app wiring, then use that client on lower levels of the app. Should I instead pass the resource on the lower levels, and when I need to call the server, do it via
.use(client => ...)?
Hi Andrey, the pattern you described where you pass the resource into the lower levels and then call it via
.use(client => ...) makes sense from my perspective! I don't know what specifically you're working on, so I can't offer more insights than that, but have you checked out our example repo for using mu? You can check it out here (https://github.com/higherkindness/mu-scala-examples/); this repo contains several examples that use mu idiomatically (here's one that does the behavior that you're describing: https://github.com/higherkindness/mu-scala-examples/blob/master/tracing/serverA/src/main/scala/com/example/ServerA.scala#L47).
java_packageoptions with the same functionality as ScalaPB. See the release notes for more!
Created higherkindness/skeuomorph#337 as there seems to be an issue with enums still requiring the
package option. Really hope it can be fixed soon, but luckily it's not a complete blocker for us.
Please let me know if I can help with it in any way.
packageoption). Doesn't seem to be skeuomorph this time, so created an issue in mu itself #1022
Is there a way to generate code from open.api where classes have more than 22 fields?
Got quite reasonable error
tuples may not have more than 22 elements, but 32 given
The settings that I setup to project are
muSrcGenIdlTargetDir := (Compile / sourceManaged).value / "compiled_openapi",
muSrcGenIdlType := higherkindness.mu.rpc.srcgen.Model.IdlType.OpenAPI,
sourceGenerators in Compile += (Compile / muSrcGen).taskValue