csharp_options.proto breaks python

[GoogleCodeExporter]

What steps will reproduce the problem?

1. Add import "google/protobuf/csharp_options.proto"; to proto file
2. Add csharp_options.proto file to a valid location in proto_path
3. Build with protoc as usual

What is the expected output? What do you see instead?

This causes an odd situation that doesn't appear to have a solution. The 
generated python file will try to import google.protobuf.csharp_options_pb2 and 
of course the python module lacks such a thing.

If you attempt to place a google/protobuf/ module in your project, it will 
override the google implementation of the entire module and similarly break the 
world.

And oddly, if you try just slapping the file in with the rest of your .proto 
files and building them that way, ProtoGen ignores the attributes and builds 
with the default settings.

What version of the product are you using? On what operating system?
2.4.1.521 on windows 7 x64

Please provide any additional information below.
The only option I need to set is option 
(google.protobuf.csharp_file_options).service_generator_type = GENERIC; but I 
didn't see any other way to pass this setting into the compiler. It also seems 
a bit odd that this option is disabled by default, as one would assume that if 
services weren't required for a project, one would simply not define them in 
the first place.

Build command for the python files is:
protoc --python_out=../ --proto_path=x:\protobuf-2.5.0\src --proto_path=./ %%P
and for C#:
protogen.exe %%P --proto_path=./ --include_imports 
--proto_path=x:\protobuf-2.5.0\src -output_directory=x:\project\Code\proto\

It's entirely possible (and likely) that I'm just being daft here, but I don't 
see a solution to this as it stands. There also doesn't seem to be a lot of 
value in namespacing csharp_options in google/protobuf/.

Original issue reported on code.google.com by fireslas...@gmail.com on 19 Sep 2014 at 6:50

[GoogleCodeExporter]

Eek. That *is* annoying. I don't have enough Python knowledge of modules etc to 
be able to suggest any definite workarounds, but two options suggest themselves:

- Can you add google.protobuf.csharp_options_pb2 to the existing module?
- Can you change the generated Python code to import a different module name, 
and provide that instead?

Both of those are only suggested as temporary workarounds, of course - I'm not 
suggesting they're long term solutions.

For some options, you can avoid putting them in the .proto file and just 
specify them as options to protogen.exe, which should (I *think*) mean you no 
longer need to have anything to do with the protos in the generated Python 
code. It doesn't help for field-specific protos though; it's only things like 
the namespace.

To be honest, the current approach for using the C# options has quite a few 
irritations. I'll consider an alternative... and try to work out how to migrate 
in a pleasant way.

Original comment by jonathan.skeet on 19 Sep 2014 at 8:36

• Changed state: Accepted

[GoogleCodeExporter]

Thanks!

The best workaround I can find for this right now is to forcefully jam the 
module into sys.modules in front of any protobuf imports. It's pretty dodgy and 
isn't super reliable but at least in my case it shouldn't matter since I'm only 
setting file level options that don't even show up in the protoc output.

import sys
import csharp_options_pb2 # Generated by protoc, but really you could probably 
just create a blank file
sys.modules['google.protobuf.csharp_options_pb2'] = csharp_options_pb2

# import as usual...
import common_pb2

Original comment by fireslas...@gmail.com on 21 Sep 2014 at 6:17

[GoogleCodeExporter]

Sorry I didn't see this earlier.

Run ProtoGen.exe /? for help and you should see that these options can usually 
be provided here.  Only for field/class specific options would the inclusion be 
required.  

For your case, run:

    ProtoGen.exe -service_generator_type=GENERIC {inputfile.proto}

Another workaround would be to create a python module for csharp_options_pb2 
that is empty.

Original comment by Grig...@gmail.com on 30 Jan 2015 at 7:02

[GoogleCodeExporter]

Closing this as there's a workaround for 2.x... I think we need to look at 
alternative ways of handling options in 3.x anyway.

Original comment by jonathan.skeet on 15 Feb 2015 at 5:27

• Changed state: WontFix