Investigate allowing optional package parameters when parsing Protobuf schema

[dmarticus]

Per this discussion in gitter

Anton Semenov @a7emenov 04:40
@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 java_package?

It seems like at least one person would want us to allow for optional package generation within skeuomorph and mu. I'm not sure at this point how significant of an undertaking that work would be but I figured it's worth making a task to track it so we can triage at some point in the future

[a7emenov]

@dmarticus, to add some clarity, my problems with the package option are:

• It is mandatory for skeuomorph to function, but not for protoc.
• It influences where the resulting files will be generated. While there are workarounds around this, I am inclined to believe it should have only "semantic" meaning, i.e. how services should be referenced.

As for a real-world example, my original .proto files do not have the package option and I cannot really change them as they are used across multiple teams. But even adding the package option is kind of fruitless without the muSrcGenIdiomaticEndpoints as clients generated by protoc will not be able to reference the service without the package prefix.

[dmarticus]

@a7emenov do you have an example protobuf file that I could work with that you'd like to be able to use with mu and skeuomorph? I'm planning on implementing this behavior this week and I'd love to have a file that you want to be able to convert to use as a test case

[a7emenov]

@dmarticus, sure, thank you so much for a swift response.

Example 1:

• File:

  syntax = "proto3";
  option java_package = "my_package";
  
  service MyService {
    rpc Check(MyRequest) returns (MyResponse);
  }
  
  message MyRequest {
    string value = 1;
  }
  
  message MyResponse {
    string value = 1;
  }
  

• Expected:
  MyService service will be generated under "my_package" package.

• Actual:
  Service generation fails as the package option is not provided.

Example 2:

• File:

  syntax = "proto3";
  package other_package;
  
  option java_package = "my_package";
  
  service MyService {
    rpc Check(MyRequest) returns (MyResponse);
  }
  
  message MyRequest {
    string value = 1;
  }
  
  message MyResponse {
    string value = 1;
  }
  

• Expected:
  MyService service will be generated under "my_package" package.

• Actual:
  MyService service is generated under "other_package" package.

[dmarticus]

Thank you for sharing! These will be some great test cases for my implementation; I appreciate it!

[dmarticus]

@a7emenov we should be releasing this change this week! Thanks for your help in providing the context around it and I hope you find the changes helpful :)

[a7emenov]

@dmarticus, I can't properly express how much this helps! Much obliged for acting so swiftly, this basically allows to keep using mu in the project. Looking forward to the release!

[dmarticus]

@a7emenov my pleasure! It's great to have users who push the envelope of what we've made and identify gaps, so I appreciate you for that. The release went out today (https://gitter.im/47deg/mu?at=5f4d6fa5dfaaed4ef521757a), and I'll publish the changes to sbt-mu-srcgen shortly.