-
Notifications
You must be signed in to change notification settings - Fork 3.7k
Minimum protobuf version is upgraded to v25.1 #6718
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
Comments
protobuf in requirements-min.txt is newer than in requirements.txt for python 3.12.
A simple fix is to change the two lines in requirements-min.txt to |
@justinchuby which python version did you have? for python 3.12 could be the correct behavior |
If he used 'pip install .' to install, pip should install a protobuf that satisfies ">=3.20.2" according to pyproject.toml, which would be the latest protobuf. We can try to change the protobuf version in pyproject.toml to a different value locally, then the corresponding protobuf should be installed. |
well that should work, because for newer python versions e.g. python 3.12 there are no corresponding old wheels at pypi? I'll have to look again at what the reason was for splitting it up and look at the old PR again to see what we might be missing |
I think we first have to clarify whether there is a problem at all and what the possible bug is? |
https://github.com/onnx/onnx/actions/runs/13444959796/job/37568087432?pr=6717 this is the error log |
IMO, the CI job installed protobuf 4.25.1 as specified requirements-release.txt but downloaded and built protobuf 5.29.2 from CMake, thus there is major version mismatch. Protobuf may not guarantees backward compatibility in this case.
to it? So that CMake will link to the system (which is usually older) protobuf. Or we update requirements-release.txt to use protobuf 5.29.2? |
I prefer not to update protobuf in requirements-release.txt, as it is not backwards compatible? Or, to formulate it differently, I would have liked to have announced this in advance, to have specified it. #6298 Adding "sudo apt-get install libprotobuf-dev" would reflect our description here: https://github.com/onnx/onnx/blob/main/INSTALL.md Currently we have https://github.com/protocolbuffers/protobuf/releases/download/v21.12/protobuf-cpp-3.21.12.tar.gz in |
I agree. I think we should match the cmake version with that in requirements-release |
The problem is that the protobuf version from requirements-release.txt should be compatible with the protobuf dev libs in mainstream Linux so that the user doesn't need to build protobuf from source when doing |
Why is building from source not a good idea? |
They have to learn concepts about building, which is extra burden. |
I think they can install from pypi right? Those who need to install from source are assumed to have special requirements for the dependencies or the building process. |
I think we need to decompose the problem now: a) do we have a stopper for 1.18 ? Do we need to change anything now before there is a release branch? => My current assessment would be no. b) Should we adjust the auto-update-doc: => I believe yes 1) that it works. What do we have to change? 2) that it is run regularly and we don't miss any issues due to updates from us or others c) Should we generally work on improving the workflow, including people compiling the project themselves. => Always, but I think we need to carefully consider the implications of the changes. |
Looks like the release picks another proto version to compile onnx, not the default one in cmake right? Aka it is compatible with the min protobuf versions we have set. That’s fine with me. However the onnx package built from source is incompatible with protobuf 4.x. So it seems like this violates the min support version we set. |
The simplest fix is to revert to "protobuf == 3.16.0" in requirements-release.txt. |
There are two protobuf versions, the one we use to build the c++ extensions & the onnx python modules, and the python package we install in the release workflow. I think what we need for the c++ version is the newest version that is compatible with the latest python protobuf version (5.x), and the min version we declare to support (3.x). So as new as we can get with max compatiblity. If whatever protobuf c++ version we use to build the pipeline to support 3.x protobuf python is too old to also work with the 5.x protobuf python, I vote that we update the min support protobuf python version, so that the onnx package we build works with 5.x. |
Also we need to use a version that does not contain any of the vulnerabilities https://security.snyk.io/package/pip/protobuf |
3.16.0 is actually very old, which was release in 2021. Our current minimum version is acceptable to me. Vulnerabilities are unavoidable, the only way to minimise them is to follow Protobuf's deprecation policy and life the minimum version for each ONNX major release. |
What do we miss if we make the following changes: #6722 , i.e. define 4.25.1 as min protobuf version? If I understand correctly, we have not been compatible with protobuf 3 for some time now? |
I think #6722 is quite reasonable |
Also, from https://pypi.org/project/protobuf/4.25.1 I realized it is possible to compile agaist a strict set of python abi to support multiple python versions with a single wheel. I wonder if we can do this with onnx? |
@andife I agree, it's better to merge safe changes first. |
### Description According to the discussion at #6718 our minimal protobuf is wrong. ### Motivation and Context <!-- - Why is this change required? What problem does it solve? --> <!-- - If it fixes an open issue, please link to the issue here. --> --------- Signed-off-by: Andreas Fehlner <fehlner@arcor.de>
To provide some context I know when upgrading onnx protobuf version in the past -- sometimes newer Protobuf version will bring breaking changes and lower version of protobuf/protoc version might not work at all. To make onnx compatible with newer Protobuf, we may need to
However, upgrading minimum required version of python protobuf might be a concern for some users and so please ensure we notify this upgrade in ONNX community in advance. Thank you guys! |
@jcwchen Thank your for comments. As I understand it, we weren't exactly clean before, so presumably the min version given for the last release was no longer correct in terms of building and executing. From this perspective, the minimal version would not change. I also think that we need to communicate clearly which core components we plan to raise and when. See also the discussion here: See also the discussion here: #6298 |
And if we life the minimum protobuf version, the instructions of INSTALL.md also need to be updated. |
Hi, just wanted to ask if someone has an estimate how long it will take to resolve this issue. As far as I can see, this is the last blocker for the 1.18 release shipping Python 3.13, which I'm waiting for 🙃 Thanks! |
@AdrianSosic You can test the rc1 at https://test.pypi.org/project/onnx/1.18.0rc1/ |
@AdrianSosic You can test the rc2 at https://test.pypi.org/project/onnx/1.18.0rc2/ |
I recently found that builds created with
pip install .
requires protobuf>5 to function. Should we double check the project's requirement?cc @andife
The text was updated successfully, but these errors were encountered: