Loosen protocolbuffers/python protobuf runtime dependency
#2053
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
We currently set a minimum version of the runtime `protobuf` package for protocolbuffers/python based on the documented ["new gencode + old runtime = never allowed"][1] rule that generally applies to the protocolbuffers plugins - that the runtime versions are free to add runtime APIs in any release and it's expected that the gencode must be updated to run with the new runtime version. However, [Python has a separate carve-out behavior for it's gencode][2], documented now as: > Since the 3.20.0 release, the Protobuf Python generated code became a > thin wrapper around an embedded FileDescriptorProto. Because these > protos are supported on extremely long timeframes, our usual major > version compatibility windows aren’t typically necessary. > Python may break generated code compatibility in specific future major > version releases, but it will be coupled with poison pill warnings and > errors in advance. As of 6.32.0, all generated code since 3.20.0 will be > supported until at least 8.x.y. This means that we don't need to pin the protocolbuffers/python version to the matching runtime version; we can loosen the minimum to `3.20.0` (and will need to reevaluate this in the future v8 major release). This commit pins the latest minor release in each major version to a minimum of 3.20. An alternative is to _just_ specify `protobuf` without any version specifiers, and allow consumers to pick the version of `protobuf` they want to supply. But since the minimum is pretty clearly documented, I think supplying it is reasonable. [1]: https://protobuf.dev/support/cross-version-runtime-guarantee/#backwards [2]: https://protobuf.dev/support/cross-version-runtime-guarantee/#python
I think we ought to just do this in one-shot, but if this is too many plugins we can revert this commit.
These types are maintained separately from the protobuf team in the typeshed repo; they are incomplete and not always correct. We ought to loosen our dependency so as to not conflict with a types-protobuf that a consumer may want to use.
Member
|
I don't think it's worth backporting this to all versions. We should pick the last ~3 and update those, and have it be the default moving forward. This is going to bump a lot of revisions, for potentially little gain. |
pkwarren
reviewed
Oct 7, 2025
pkwarren
approved these changes
Oct 7, 2025
Member
pkwarren
left a comment
pkwarren
left a comment
There was a problem hiding this comment.
I think we may at some point just want to remove all version constraints and let downstream projects choose their versions (especially since version selection is so expensive).
Happy to start with this though.
stefanvanburen
deleted the
svanburen/backport-python-loosen-protobuf-dep
branch
Member
Agreed. Thanks for the updates @stefanvanburen 🎉 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We currently set a minimum version of the runtime
protobufpackage for protocolbuffers/python based on the documented "new gencode + old runtime = never allowed" rule that generally applies to the protocolbuffers plugins - that the runtime versions are free to add runtime APIs in any release and it's expected that the gencode must be updated to run with the new runtime version.However, Python has a separate carve-out behavior for its gencode, documented now as:
This means that we don't need to pin the protocolbuffers/python version to the matching runtime version; we can loosen the minimum to
3.20.0(and will need to reevaluate this in the future v8 major release).This commit pins the latest minor release in each major version to a minimum of 3.20.
An alternative is to just specify
protobufwithout any version specifiers, and allow consumers to pick the version ofprotobufthey want to supply. But since the minimum is pretty clearly documented, I think supplying it is reasonable.types-protobufdependency of protocolbuffers/pyi, but we don't have any real guarantees about how those versions map to the runtime version. I think we ought to loosen them to just allow the user to figure out the version they want. Again, we can revert this, but I figure we ought to do this update in one-shot.