search

google / proto-lens

API for protocol buffers using modern Haskell language and library patterns.
https://google.github.io/proto-lens
BSD 3-Clause "New" or "Revised" License
460 stars 110 forks source link

Support filepaths with `dots`. #153

Open lucasdicioccio opened 6 years ago

lucasdicioccio commented 6 years ago

Hi, again. On top of #152 I had to make another workaround for the project I was using: the project had a directory with a UNIX-hidden-directory such as .protodir/myfilename.proto . The current plugin will generate modules named Proto..protodir.MyFileName, which is invalid Haskell.

As for the other bug I filed, I wanted to discuss with you the best implementation choices before making a proper pull request. You can find my patches at: https://github.com/google/proto-lens/compare/master...lucasdicioccio:workarounds .

judah commented 6 years ago

Thank you for the report. I have mixed feelings about such a change, as well as the discoverability of such a feature. If the user doesn't put the right module name ahead of time in exposed-modules, then proto-lens won't generate code for that .proto file, and the user will need to know ahead of time to use the magic "Dot" replacement in the module name.

At the least, though, we should change the proto generation code to detect if any of the proto files have a . in their path and give a better error message.

In your project, would it have worked to pass the full path to .protodir as the root dir (for example: main = defaultMainGeneratingProtos ".protodir") so that .protodir/myfilename.proto would just become Proto.Myfilename? If so, that would be my preference for the level that we support. But if not, let us know and we can consider another approach.

judah commented 6 years ago

Another possibility would be to allow overriding the generated module name, similar to: https://github.com/google/protobuf/blob/master/src/google/protobuf/descriptor.proto#L324 which might solve a more general class of such problems. Though that would probably require implementing #27 to be able to use Haskell-specific custom options, similar to ScalaPbOptions