-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Bump the proto requirements to match the generated data. #4473
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
Bump the proto requirements to match the generated data. #4473
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is actually a pain point for compatibility between TFQ and CIrq. We manually compile our .proto
files using grpcio-tools
(which comes with a recommended protoc inside) and keep them in the repo. Right now, the release version of TensorFlow Quantum depends on TensorFlow 2.4.1 which requires proto 3.9.2, but will work up to cirq having proto 3.13.0 or lower. Is this proto bump happening because you found something breaking or because there were warnings ?
@MichaelBroughton I encountered an error:
https://github.com/tensorflow/quantum/pull/621/checks?check_run_id=3425375706 I was able to repro locally, and I was able to fix by bumping the version of protobuf. But, from what I now understand, this is a naive approach and bumping the version won't work. Is there another way? Maybe PR #4333 was compiled with the wrong version of |
I think I was able to resolve the issue, @MichaelBroughton . Instead of bumping the requirements, I had to regenerate the files. I also added a discussion item for next week's Cirq sync. |
We used to have a CI check that would generate protos with the expected version of the proto compiler and fail if there were any diffs compared to what was in the PR. Is that no longer running? If there's a diff like this I would have expected either a previous PR to be rejected, or this one. |
From Cirq Cync: Could you regenerate and test with the following:
And then bump: https://github.com/quantumlib/Cirq/blob/master/cirq-google/requirements.txt |
Thanks. PTAL. |
So you regnerated all the |
Yes, precisely. I used the commands in the description. |
Awesome. @dstrain115 @maffoo does this work for you guys to merge ? |
I think the For this PR, I think updating the protobuf library is probably ok, but I'd prefer to update the |
Thanks for answering. I am a little bit confused though. I did run
After running the commands, the proto files reverted themselves to their version at head. In other words, I did not manually revert the changes. Instead, I kept the intermediate (and incorrect) changes that I had, and by running the script, they naturally got reverted. Sorry if I am still confused and thanks for having taken the time to review the changes. |
Like this: |
@tonybruguier, I think the problem is that the .proto files we have committed at HEAD are not correct because our CI check is broken. The CI should be compiling with grpcio-tools==1.26.0 which is what is listed in the the proto deps: https://github.com/quantumlib/Cirq/blob/master/dev_tools/requirements/deps/protos.txt#L6. If you do that you'll see a big diff compared to what is committed at HEAD. But our CI check didn't detect the problem whenever the latest proto changes were committed. |
@maffoo Thanks. I looked into the test code and I think I might have found an issue: It seems that it was only checking changed files, which is not correct I think. When we bump the requirements, we don't modify the proto definitions, yet their compiled version might be different. I tried the fix the unit test, and also updated the requirements. Here's the log: It now seems to be finding the protos and to re-generate them. |
Thanks, @maffoo PTAL when you have the time. I appreciate the quick turn-around and the opportunity to learn. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is looking much better, thanks for working through these protobuf issues! I think we should run some tests to ensure that the ci task to check generated protobuf code is working. For example, make a change to a .proto
file and push this branch without regenerating proto code and verify that the CI check fails. Similarly, could make an edit directly to one of the generated _pb2.py
files and again verify that the CI check fails. This will ensure that we can keep our proto code properly synced going forward.
I'll let @MichaelBroughton weigh in on what protobuf version we actually want to upgrade to, but I do think we should keep that in sync here with our grpcio-tools version.
Thanks, @maffoo |
Closed remaining comments and sync'ed to head. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tooling looks good, thanks for fixing/simplifying the CI check. I'd suggest changing the protobuf dependency per Michael's suggestion and a few minor doc fixes, then we should be good to go.
Thanks. PTAL. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
…4473) It seems PR quantumlib#4333 used a newer version of the proto syntax, but the requirements have not been updated, so this PR bumps them, As a check, I decided to execute the follow commands: ``` python3 -m pip install protobuf~=3.17.3 python3 -m pip install grpcio-tools~=1.34.1 python3 -m pip install grpcio~=1.34.1 python3 -m pip install mypy-protobuf==1.10 ./dev_tools/build-protos.sh ``` And the generated protos are unchanged, so maybe it's correct?
It seems PR #4333 used a newer version of the proto syntax, but the requirements have not been updated, so this PR bumps them,
As a check, I decided to execute the follow commands:
And the generated protos are unchanged, so maybe it's correct?