#grpc

hey guys, i'm wondering if there are any guarantees about language backward-compatibility in protobuf

*syntax

err sorry

i mean the text encoded format

zls_: Hmm... I don't know. I do know it is frequently used as an on-disk format for configuration, so changing it would cause pain.

ejona: that's exactly what we're studying about doing. I believe the binary format is back-compatible so i'm not sure why the text version wouldn't be

zls_: Well, they are different formats and the text format is not as clearly specified. I'd have no reservation of using it for configuration.

I think it may have been intended as a debug-only format. But it has grown to be much more than that.

I can ask a protobuf dev about it. But I don't know of any "official" "this won't change" messaging.

stupid question: why would you want to prefer the text version over the binary version ?

I see teams do it when they want to provide configuration to their application. The configuration may be checked in to source control.

(And hand modified)

myeah

You could convert that to binary proto as part of the build process, but it still expects the format to be fixed.

As a concrete example, we did that with the interop tests to define which tests should be run :)

I personally find that a piece of json might look a bit more tractable as a configuration file

zls_: Actuall, |Pixel| brings up a good point. In proto3 the JSON is the "preferred text format". So you may use that instead.

yeah we want text because we want it to be sensible for a human to look at and understand

having some weird issues with grpc proto includes an imports

You're still having the import loops?

well i'm trying various things to see what works best. Go and python together dont mix well

I wanted to set the include path to $GOPATH/src but that generates retardedly long import paths

if I want to use the same imports, I need to make the include paths work correctly and mimic the structure which is a major pita

Oh, I see. I don't know what the recommendation is for Go.

But I do understand.

i guess its really a problem with imports

I dont feel like making symlinks everywhere but that's the most reasonable way I can see

Or silly amounts of include paths

yeah. I wanted to coy go imports out of convenience. so you'd have a .proto file with .. import "github.com/lungaro/whatever/service.proto";

cop=copy*

. in a name doesn't play well w/ python either

Yeah, but that would be a go-ism, which proto wouldn't share with other languages.

i mean all i'm talking about though is protoc getting the correct .proto file included

its like I need the ability to strip a prefix on output

afaics the location of the .proto file determines the generated include path, correct?

Using the "normal" include and then using -I with protoc seems going with the flow more.

I think there is a mapping that Go allows.

(with -M)

It's just M