You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It appears that due to the Item message not being in the proto file passed in to the truss command the package is having an issue with formatting the type in to this section of code. Further down in the submain() function the variable flagItemPostItem is referenced so it seems whatever is generating this code is able to get the correct name.
Moving the Item message type into the proto file and removing the import solves the issue and the following code for the section that contained the misgenerated bit looks normal:
Currently there are issues with having multiple protobuf packages.
Reasons include:
Default truss behavior of putting generated .pb.go files into a different directory than the .proto files that defined them. This confuses protoc-gen-go which truss uses to generate the .pb.go files.
Proto packages imported in a .proto file used with truss must be imported by their full path relative to $GOPATH/src. This is so that the generated go code will have a proper import path that is buildable.
Different proto packages must reside in different directories if they are going to become go packages. This is because go enforces one package per directory.
For truss to be "turn key", truss should read the imports in the .proto file that it is called on, then recursively call protoc-gen-go on those imports, to generate the go package for those imports.
When generating a service from a proto file that includes an import for a shared message I receive the following:
The proto files:
As a result of this warning/error the following code is generated in
listings/cmd/listings/main.go
in the functionsubmain()
:It appears that due to the
Item
message not being in the proto file passed in to thetruss
command the package is having an issue with formatting the type in to this section of code. Further down in thesubmain()
function the variableflagItemPostItem
is referenced so it seems whatever is generating this code is able to get the correct name.Moving the
Item
message type into the proto file and removing the import solves the issue and the following code for the section that contained the misgenerated bit looks normal:The text was updated successfully, but these errors were encountered: