Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Code Formatting Error When Generating Services Using Shared Message Types #201

Open
kylieCat opened this issue Jul 24, 2017 · 1 comment
Labels

Comments

@kylieCat
Copy link

When generating a service from a proto file that includes an import for a shared message I receive the following:

vader:gopherup ian$ truss proto/listings-svc.proto --svcout=./listings
WARN[0000] Code formatting error, generated service will not build, outputting unformatted code  error=92:1: expected 'IDENT', found '%' (and 10 more errors)

The proto files:

// listings-svc.proto
syntax = "proto3";
package gopherupListings;

import "common.proto"
import "github.com/TuneLab/truss/deftree/googlethirdparty/annotations.proto";


// Request messages

message PostItemRequest {
    gopherupCommon.Item Item = 1;
}
// common.proto
syntax = "proto3";
package gopherupCommon;

enum ItemState {
    LISTED = 0;
    ARCHIVED = 1;
    SOLD = 2;
    HIDDEN = 3;
}

message Item {
    int64 ID = 1;
    string Title = 2;
    string Description = 3;
    int64 Price = 4;
    ItemState State = 6;
}

As a result of this warning/error the following code is generated in listings/cmd/listings/main.go in the function submain():

var (
		flagItemIDArchiveItem = fsArchiveItem.Int64("itemid", 0, "")
		%!(EXTRA string=flagItemPostItem, string=PostItem, string=item, string="")
		%!(EXTRA string=flagItemEditItem, string=EditItem, string=item, string="")
		flagItemIDGetItem = fsGetItem.Int64("itemid", 0, "")
		flagItemIDMarkItemSold = fsMarkItemSold.Int64("itemid", 0, "")
	)

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:

var (
		flagItemIDMarkItemSold = fsMarkItemSold.Int64("itemid", 0, "")
		flagItemIDArchiveItem  = fsArchiveItem.Int64("itemid", 0, "")
		flagItemPostItem       = fsPostItem.String("item", "", "")
		flagItemEditItem       = fsEditItem.String("item", "", "")
		flagItemIDGetItem      = fsGetItem.Int64("itemid", 0, "")
	)
@adamryman
Copy link
Member

Thank you for reporting this issue.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants