Re: [protobuf] Question about Go protobufs and import_prefix

2016-07-12 Thread Zellyn Hunter
. square/up/protos/square.proto >> $ cp /tmp/x/square/up/protos/square.pb.go square/up/protos >> >> The generated .go files will reference non-vendored paths, which the Go >> compiler will resolve to the correct vendored directory. >> >> Does that seem l

Re: [protobuf] Question about Go protobufs and import_prefix

2016-07-10 Thread Zellyn Hunter
Usually not too tricky. The problem is that protos and most other programming languages prohibit circular imports at the file level, and Go does it at the package level. The fact that protoc and the other languages are okay with a topology ensures there is a valid Go repackaging that will work.

Re: [protobuf] Question about Go protobufs and import_prefix

2016-07-01 Thread Zellyn Hunter
Oh wow. Thanks for thinking about it so carefully! I should mention: before you could actually specify full package paths to the Go proto plugin, earlier versions of our wrapper ( https://github.com/square/goprotowrap) just forcibly manhandled things into the shape we wanted by explicitly

Re: [protobuf] Proposal: a mechanism to deal with sensitive/redacted fields in string output

2019-05-13 Thread Zellyn Hunter
On Fri, May 10, 2019 at 6:06 PM Adam Cozzette wrote: > I asked for feedback about this proposal within Google and unfortunately > it sounds like there's not a lot of support for accepting this kind of > change. The general feedback I got was that it's best to simply avoid > printing out any

Re: [protobuf] Proposal: a mechanism to deal with sensitive/redacted fields in string output

2019-04-25 Thread Zellyn Hunter
Hey there, just checking in from Paternity Leave. Last I heard, the Protobuf team was not opposed to the idea, but thought it would be relatively invasive and thus unlikely to get accepted. I believe that it will hardly be invasive at all, so I think the most-likely-to-succeed course of action is