More permissive protobuf version for opentelemetry-exporter-prometheus-remote-write

[michaelschuett-tomtom]

Description

This change for my case it to allow us to use this in a project that needs to use protobuf 5.29. I have tested in that project that everything still works as expected so the version limit is only based on the restriction in the produced pypi package not on any code limitation.

I originally was looking at saying the package uses =~5.29 however this conflicts with another random package I had installed streamlit 1.30.0 requires protobuf<5,>=3.20, but you have protobuf 5.29.3 which is incompatible. Which made me think it might be nice to let people use all known working versions of protobuf with this package instead of arbitrarily deciding what one is correct.

Fixes #3179

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

I tested locally by running

$ PACKAGE_NAME=opentelemetry-exporter-prometheus-remote-write VERSION=1.0 ./scripts/build_a_package.sh
$ pip install --force-reinstall ./dist/opentelemetry_exporter_prometheus_remote_write-0.51b0.dev0-py3-none-any.whl

Does This PR Require a Core Repo Change?

• Yes. - Link to PR:
• No.

I don't think so?

Checklist:

See contributing.md for styleguide, changelog guidelines, and more.

• Followed the style guidelines of this project
• Changelogs have been updated
• Unit tests have been added
• Documentation has been updated

[linux-foundation-easycla]

• ✅login: michaelschuett-tomtom / (df710aa)

The committers listed above are authorized under a signed CLA.

[emdneto]

Hey: thanks for the PR. I think we should at least add a test using protobuf 5, although tests pass and there is no guarantee for cross-version runtime. What we did in opentelemetry-proto was to support only one major version, protobuf 5.

@aabmass do you think we should wait for the protobuf Q12025 release for this kind of issue?

[aabmass]

Which made me think it might be nice to let people use all known working versions of protobuf with this package instead of arbitrarily deciding what one is correct.

It's not arbitrary like @emdneto mentioned, protobuf makes it very clear that this is not officially supported. This PR lets the user decide but I fear people will come here when things break and expect us to fix it. I would prefer to do what @emdneto mentioned and just support protobuf 5. It's been out for almost a year now.

Is there a not a newer streamlit version that works with protobuf 5?