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

Can't really use twirp generator with go modules from 1.11 #127

Closed
dbudworth opened this issue Sep 15, 2018 · 1 comment
Closed

Can't really use twirp generator with go modules from 1.11 #127

dbudworth opened this issue Sep 15, 2018 · 1 comment

Comments

@dbudworth
Copy link
Contributor

When using go modules outside the GOPATH, you have to specify the option go_package in your .proto files
This is due to having no base directory where your full import path lives, so you have to change your .proto imports to be relative

Once you use relative imports, you have to use option go_package as the google generator will incorrectly guess import path as it really just takes the dir name of the .proto import path

When you specifty the go_package name, google (and twitch) code generators attempt to write the generated .go file to that fully qualified import path, which doesn't work as your project really starts at the repo portion and not the github.com/USER bit

Google generator offers a paths=source_relative option that will write the go file in whatever dir the .proto is in, which is generally what you'd want.

I've submitted #126 to address this
It both adds support for the option paths=source_relative, same as go's protoc plugin
it also uses the import path declared by option go_package

This isn't directly go module support, but it is needed if your project uses modules.

In the future, proper module support should be added, but I'd hold off until the go team adds module processing to the stdlib as all tooling around it now have to take stuff from vgo's internal packages to even read the custom file format go.mod uses

@spenczar
Copy link
Contributor

I'm closing this as fixed in #126.

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

No branches or pull requests

2 participants