Description
What version of protobuf and what language are you using?
Version: 5.28.0
Language: Python
What operating system (Linux, Windows, ...) and version?
Linux, but not relevant
What runtime / compiler are you using (e.g., python version or gcc version)
Compiler 5.27.2, runtime 5.28.0
What did you do?
Compile a .proto using the libprotoc 27.2 compiler, then run my code using the v.5.28.0 runtime.
What did you expect to see
I expect this to work without fuss, since it is a supported configuration according to https://protobuf.dev/support/cross-version-runtime-guarantee/#minor
What did you see instead?
A Python warning is emitted, saying:
google/protobuf/runtime_version.py:112: UserWarning: Protobuf gencode version 5.27.2 is older than the runtime version 5.28.0 at path/to/example.proto. Please avoid checked-in Protobuf gencode that can be obsolete.
This is a new warning that was intentionally added in v5.28.0 as a result of #17241. It seems excessive however as it can't easily be avoided in many situations, and can be awkward to disable. For example, I need the v5.28.0 runtime (due to a specific bugfix that's not in 5.27.x), however I also have some GRPC services, plus I use the mypy-protobuf plugin, so my build scripts can't just call the protoc 5.28.0 compiler binary directly. Instead, I am using a build venv containing grpcio-tools (which only has the 27.2 compiler). This means I can't reasonably avoid the runtime warning, and so have to jump through hoops to suppress it. See also GRPC issue grpc/grpc#37609 for further discussion on the impact of this. Given grpcio-tools always tends to lag the latest protoc version, I imagine others will encounter similar situations with this warning on an ongoing basis too.
It seems to me that a solution should really lie with the protobuf project rather than grpc. I appreciate the reasoning behind the new warning, but having a way to prevent the protoc compiler generating it (e.g. via a --warning-level <n> flag on protoc?) would make life a lot easier for people in situations like mine. As it stands I'm having to add several __init__.py files to various repositories, as well as generate some more of them dynamically from both makefiles and bazel scripts, to work around this issue.
Activity