pulumi: No upper bound on python dep protobuf results in latest protobuf version breakage (protobuf>=4.21.0)
What happened?
I was deploying a new stack when I reached a long traceback that ultimately ended with a protobuf error:
File "/opt/hostedtoolcache/Python/3.9.12/x64/lib/python3.9/site-packages/google/protobuf/descriptor.py", line 560, in __new__
_message.Message._CheckCalledFromGeneratedFile()
Log: https://github.com/CouncilDataProject/denver/runs/6604387518?check_suite_focus=true
Steps to reproduce
I can’t think of a minimal reproducible example at the given moment…
Expected Behavior
Infrastructure deploy to proceed without fail. This same stack configuration completed just fine just hours prior: https://github.com/CouncilDataProject/portland/runs/6597117332?check_suite_focus=true
When I ran a text diff against the two install lists, the only difference between the installed Python packages was protobuf-3.20.1 (succeeding) and protobuf-4.21.0 (failing)
Actual Behavior
Until latest version of protobuf is supported, install should use protobuf>=3.6,<4.21.0 and succeed.
Versions used
OS: Ubuntu 20.04.4 Python: 3.9.12 Pulumi (Python): 3.33.1 pulumi/actions: 3.33.1
Full Python package installed:
Successfully installed aiohttp-3.8.1 aiosignal-1.2.0 arpeggio-1.10.2 async-timeout-4.0.2 attrs-21.4.0 cachetools-5.1.0 cdp-backend-3.0.16 certifi-2022.5.18.1 charset-normalizer-2.0.12 dataclasses-json-0.5.7 decorator-5.1.1 dill-0.3.5.1 fireo-1.5.0 frozenlist-1.3.0 fsspec-2022.5.0 gcsfs-2022.5.0 google-api-core-2.8.0 google-auth-2.6.6 google-auth-oauthlib-0.5.1 google-cloud-core-2.3.0 google-cloud-firestore-2.3.4 google-cloud-storage-2.3.0 google-crc32c-1.3.0 google-resumable-media-2.3.3 googleapis-common-protos-1.56.1 grpcio-1.46.3 grpcio-status-1.46.3 idna-3.3 marshmallow-3.15.0 marshmallow-enum-1.5.1 multidict-6.0.2 mypy-extensions-0.4.3 oauthlib-3.2.0 packaging-21.3 parver-0.3.1 proto-plus-1.20.4 protobuf-4.21.0 pulumi-3.33.1 pulumi-gcp-6.24.0 pulumi-google-native-0.19.1 pyasn1-0.4.8 pyasn1-modules-0.2.8 pyparsing-3.0.9 pyyaml-6.0 requests-2.27.1 requests-oauthlib-1.3.1 rsa-4.8 semver-2.13.0 six-1.16.0 typing-extensions-4.2.0 typing-inspect-0.7.1 urllib3-1.26.9 yarl-1.7.2
Additional context
Looks like this was unpinned in https://github.com/pulumi/pulumi/pull/9337
Contributing
Vote on this issue by adding a 👍 reaction. To contribute a fix for this issue, leave a comment (and link to your pull request, if you’ve opened one already).
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Reactions: 6
- Comments: 17 (10 by maintainers)
Commits related to this issue
- Pin python protobuf to <4 Fixes https://github.com/pulumi/pulumi/issues/9694 — committed to pulumi/pulumi by Frassle 2 years ago
- Pin python protobuf to <4 (#9696) * Pin python protobuf to <4 Fixes https://github.com/pulumi/pulumi/issues/9694 * Add to CHANGELOG — committed to pulumi/pulumi by Frassle 2 years ago
Folks, we are working on a release to mitigate this issue!
This is back. Just hit it in our env. I also see Protobuf 4.21.0 is back on pypi.
Folks we are looking into this immediately - thanks for raising the issue! We see the same problem on some of our nightly acceptance test runs
@denniswebb patched version v3.33.2 has been pushed
I have reran my infrastructure deploy job after the protobuf release was yanked and it worked (https://github.com/CouncilDataProject/denver/runs/6613594089?check_suite_focus=true). So for the time being we are seemingly okay but definitely something to pin for the future it seems.
Thanks all for the fast response ❤️
We looked into that but setting the pinned version still caused a whole load of our test to fail with the same issue. We have multiple engineers investigating multiple approaches to fix this.
Just adding to this, same issue.
Current workaround is pinning
protobuf==3.20.1in myrequirements.txtSome additional error messages:
https://developers.google.com/protocol-buffers/docs/news/2022-05-06#python-updates
This might be related to generate.sh ?