Dual libprotobuf pin

[xhochy]

Comment:

I have several environments that don't resolve with newer versions anymore because our libprotobuf pin is only supporting the protobuf>=4 Python package. This causes several headaches for me as tritonclint-grpc (can be changed with the next release to <4) or streamlit have a pin for <4. These are only two possible examples and it seems that many other packages are still on protobuf=3. This is not a problem in the Wheel world as there everyone ships a static protobuf build.

Thus I would suggest to have two libprotobuf versions in our global pinning until the end of July 2023 (we need a point where we can drop it again, and half year's time from now seems reasonable).

cc @conda-forge/libprotobuf @conda-forge/core

[hmaarrfk]

can you confirm that these upper bounds are intentional given the new versionning scheme from libprotobuf?

The alternative seems to be to loosen them.

[h-vetinari]

So far (up until the most current 21.12 == 3.21.12 == 4.21.12), only the python bindings had v4, see here. C++ never needed v4 so far, so up until now, a v4 for libprotobuf makes no sense.

It's possible that other packages are confused by the new protobuf versioning scheme.

The upcoming 22.0 == 3.22.0 == 4.22.0 will also bump the C++ major number, however, I don't expect things to work much different than before, and I don't think it's necessarily a great idea to build for two protobuf versions (given it's relatively widespread), unless we expect the API changes to take a while to digest, but overall the breaking changes don't look too unusual (mostly meta-level like now depending on abseil or reserving C++20 keywords).

[xhochy]

can you confirm that these upper bounds are intentional given the new versionning scheme from libprotobuf?

Yes, they are intentional according to the upstream maintainers. I haven't looked into the breakages but I saw responses from maintainers saying that there is worked needed to support the new version.

[hmaarrfk]

Understood. I am mostly weary about the tensorflow builds that need to be done manually.

[h-vetinari]

can you confirm that these upper bounds are intentional given the new versionning scheme from libprotobuf?

Yes, they are intentional according to the upstream maintainers. I haven't looked into the breakages but I saw responses from maintainers saying that there is worked needed to support the new version.

From the last ~2 years of experience, one can pretty safely ignore what bounds people set on protobuf. Most of the time it's to deal with their distribution on PyPI, not having tested it yet, etc.

Protobuf keeps its API very stable, so once things are recompiled, we should be good. I prefer to make doubly sure by running the respective test suite in our CI, and once that passes, I have no qualms to overrule some upstream protobuf pins/caps.