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

Improve support for go_package option in .proto files #126

Merged
merged 2 commits into from
Sep 24, 2018

Conversation

dbudworth
Copy link
Contributor

@dbudworth dbudworth commented Sep 14, 2018

Previously, specifying the option go_package caused the generator
to write a file to the fully qualified path
This would create the full directory tree

this doesn't really work as it adds, to your project root dir, the full github.com/blah/...
structure

This change does two things
adds support for the paths=source_relative like the google protoc plugin does
which ensures we write to whatever directory the .proto file lives in

secondly, it makes sure to use whatever go_package says when importing the module.
It was generating imports with relative dirs from the project root

With these two changes, you can use twirp with go 1.11's modules now

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Previously, specifying the option go_package caused the generator
to write a file to the fully qualified path
This would create the full directory tree

this doesn't really work as it adds, to your project root dir, the full github.com/blah/...
structure

This change does two things
adds support for the `paths=source_relative` like the google protoc plugin does
which ensures we write to whatever directory the .proto file lives in

secondly, it makes sure to use whatever go_package says when importing the module.
It was generating imports with relative dirs from the project root

With these two changes, you can use twirp with go 1.11's modules now
@spenczar
Copy link
Contributor

This sounds great, I totally agree that it is needed. I’m on vacation but should be able to take a closer look on Monday or Tuesday. Thanks very much.

Copy link
Contributor

@spenczar spenczar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks like a great improvement to workflows, thanks. Got one minor change I'd like you to make.

I'll add documentation and a test case too.

@@ -47,6 +47,9 @@ type twirp struct {
importPrefix string // String to prefix to imported package file names.
importMap map[string]string // Mapping from .proto file name to import path.

// Package output:
paths string // instruction on where to write output files
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's make this sourceRelativePaths bool instead of a string with a particular value.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done, makes sense. Not sure what I was thinking on that initial commit.

Initial commit was threading the string value through the system
Now, we just interperet the option up front and use as a bool in
later parts
@dbudworth
Copy link
Contributor Author

On a total side note, if you wanted to use twirp with a go module based project (that doesn't live in GOPATH), adding:

replace github.com/twitchtv/twirp => github.com/peak6/twirp v0.0.0-20180919094615-eddc651701575ab8a9ed24c61a995a5bd49d2ddb+incompatible

to go.mod makes your project use the fork.

I DO NOT suggest folks actually build against my fork as I'm not intending to maintain the fork past this pull request.

I'm just posting it merely to unstick anyone who's currently stuck, or in case folks are trying to figure out in general how to override deps.

@dbudworth
Copy link
Contributor Author

Just checking in, was the bool change what you were expecting?

@spenczar
Copy link
Contributor

@dbudworth this looks great, I was just away from github for a few days. Thanks!

@spenczar spenczar merged commit 0caa60e into twitchtv:master Sep 24, 2018
@rynop rynop mentioned this pull request Jun 17, 2019
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

Successfully merging this pull request may close these issues.

2 participants