Note that I'm not actually generating protobufs into a vendor folder; what
I described has the same problems with or without vendoring.
On Tuesday, July 12, 2016 at 4:33:33 PM UTC-4, Damien Neil wrote:
>
> Simpler than maintaining a fork, though.
>
> The more convenient alternative would be for p
Simpler than maintaining a fork, though.
The more convenient alternative would be for protoc to understand Go vendor
directories, but that would require putting some Go-specific logic in
protoc itself.
On Tue, Jul 12, 2016 at 8:00 AM, Zellyn Hunter wrote:
> Yeah I can do anything with a wrapper
(Apologies if you get two copies of this mail; resending to the list
because my first try bounced.)
If I'm following this correctly, your core problem is that protoc doesn't
understand vendored paths as used by the go tool. For example:
- You have a proto file located in src/square/up/protos/sq
Zellyn and I talked a little bit at Gophercon about this. I think some kind
of wrapper is in order for his use case: it may actually be a filter
between protoc and protoc-gen-go.
On Tue, Jul 12, 2016, 8:49 AM Damien Neil wrote:
> If I'm following this correctly, your core problem is that protoc
If I'm following this correctly, your core problem is that protoc doesn't
understand vendored paths as used by the go tool. For example:
- You have a proto file located in src/square/up/protos/square.proto.
- square.proto imports "
github.com/golang/protobuf/ptypes/timestamp/timestamp.proto".
- ti
Yeah I can do anything with a wrapper. But to the extent that our concerns
and structure are normal, it would be a shame to need a wrapper.
On Tue, Jul 12, 2016, 8:54 AM Ross Light wrote:
> Zellyn and I talked a little bit at Gophercon about this. I think some
> kind of wrapper is in order for h
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.
Ze
I don't know the background of the Go import system or go_package option.
However this statement concerns me a little:
> We have to use go_package to reorganize things that are fine in
Java/Ruby, but would be circular package imports in Go.
Is this implying that certain .proto files would gener
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 specifyi
+Ross who is working on Go protobuf.
Ross, do you have any comments or suggestions?
On Fri, Jun 24, 2016 at 8:35 AM, Zellyn wrote:
> Hi folks,
>
> Apologies in advance for the complex email. It takes a bit of explaining
> to set up what we're having trouble with.
>
> I would like to lay out how
Hi folks,
Apologies in advance for the complex email. It takes a bit of explaining to
set up what we're having trouble with.
I would like to lay out how we generate protos in Go (using our
unfortunately forked version of the protoc plugin), and ask for suggestions
as to how to accomplish the s
11 matches
Mail list logo
