-
Notifications
You must be signed in to change notification settings - Fork 419
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
grpc-gen-swift generates all dependency protos instead of only requested ones #1057
Comments
Agh, sorry for regressing this @jagobagascon. |
Thank you for the quick response! |
Hi! This issue is messing with our automated build (the code does not compile) and we want to avoid using a specific commit so, is it too much to ask for an Thanks! |
There are a couple of outstanding PRs which I'd like to get merged then I'll happily tag a release for you. ETA is next couple of days if that's not too big a problem for you? |
Two days is completely acceptable 😄 . Thank you very much! |
@jagobagascon done! Thanks for your patience with this one. |
Describe the bug
We recently upgraded form version
alpha.14
toalpha.20
. After this change, when we try to generate a proto that has a dependency on another proto, the generator is creating code for both protos (and not only the requested one).Let's say
foo.proto
depends onbar.proto
, we generate both independently and move each of them to a different swift module. After upgrading toalpha.20
generatingfoo.proto
is creating files forbar.proto
(which I think is wrong).To reproduce
I created this repo for another bug, but it can be reproduced by calling
make generate
in it: ModuleB will contain code generated fromb.proto
and ModuleA will contain both code generated froma.proto
and alsob.proto
.https://github.com/jagobagascon/grpc-swift-modules-test
Expected behaviour
grpc compiler should only generate code for explicitly passed protos, not its dependencies.
Additional information
This happened in the past and was fixed in this PR. I think this is a regression added in this commit.
Unless it was added by some reason, I think that reverting back to the change made by the PR should fix this problem.
The text was updated successfully, but these errors were encountered: