Right now, a .proto file can have a line like
option go_package = "foo";
which means that the generated .pb.go file should have a package foo statement.
I am proposing to overload this option with two new possible syntaxes:
option go_package = "github.com/example/foo";
This means that generated code should be dropped into the github.com/example/foo directory (relative to whatever is passed to protoc's --go_out flag), overriding the default behaviour of matching the path to the .proto file. It also means the .pb.go file should have a package foo statement.
option go_package = "github.com/example/foo;bar";
This means the same as the previous syntax, but additionally means that the .pb.go file should have a package bar statement, for the rare cases where people want the package name to differ from the final path component of the import path.
This would hopefully mean that far fewer M parameters need to be passed through the --go_out flag. It would subsume #137 and maybe #63.
Thoughts? Opinions?
@robpike @zellyn @mwitkow @awalterschulze @peter-edge @tamird
Right now, a
.protofile can have a line likewhich means that the generated
.pb.gofile should have apackage foostatement.I am proposing to overload this option with two new possible syntaxes:
This means that generated code should be dropped into the
github.com/example/foodirectory (relative to whatever is passed to protoc's--go_outflag), overriding the default behaviour of matching the path to the.protofile. It also means the.pb.gofile should have apackage foostatement.This means the same as the previous syntax, but additionally means that the
.pb.gofile should have apackage barstatement, for the rare cases where people want the package name to differ from the final path component of the import path.This would hopefully mean that far fewer
Mparameters need to be passed through the--go_outflag. It would subsume #137 and maybe #63.Thoughts? Opinions?
@robpike @zellyn @mwitkow @awalterschulze @peter-edge @tamird