Fix version guessing for protoc

[s9105947]

Dear maintainers,

this PR fixes a problem which I encountered when using metricq-python not via pip.

Note that as this tests the installation process, for which unit testing is not implemented in metricq-python:
There are no tests included in this PR. I am confident that manual review will be sufficient for this small change.

How well this approach will work in practice is not clear to me, as it requires an exact match of the protobuf version during runtime.
However, it is the best solution I came up with given the circumstances.

Description:

During the build process, protoc is invoked to build protobuf files. These built files are deployed to users, and thus the users require a compatible python-protobuf version at runtime.

For that, the required protobuf version is set during the build process in setup.py. However, this version selection is not up to date with the versioning scheme used by protobuf. protobuf keeps the major version independent between languages, and minor/patch versions in sync. E.g., as of the time of writing, python-protobuf 4.21.12 is compatible with libprotoc 3.21.12.
see: https://protobuf.dev/news/2022-05-06/

However, it is not clear under which circumstances these versions are compatible to each other. (I.e., even if minor/patch version are different, the binary format may still be compatible.) This makes correctly predicting the required (potentially unrealeased) python-protobuf version impossible.

This patch takes a conservative approach: It manually ensures that minor/patch versions align during build, and then requires the exact python-protobuf used during building also during runtime. As a consequence, only readily available python-protobuf versions should be used during building, in order to prevent complications for users.

[s9105947]

quick notes from discussion:

This approach is correct, but not practical.
We must be able to read the protoc installed from system (be it Debian Ramses or Archlinux) and require the correct python-protobuf version from pypi.
This PR in its current state requires already correct dependencies (i.e. moves the problem to the setup of the build/dev machines), but is not capable of guessing the correct python-protobuf version purely from the installed protoc version.

[bmario]

What did we end up deciding to do as a path forward?

[s9105947]

we decided nothing.

it might be acceptable to wait for upstream, as in the respective issue they note that:

The good news is that I have something in progress that should define this more carefully and I will try to publish it in the next month or so (holidays may interfere)

With "the next month" being Jan 2023.

so ¯\_(ツ)_/¯

[tilsche]

I thought the plan was on the whiteboard?
It is also referenced at the bottom of my rant protocolbuffers/protobuf#11123 (comment)

What we came up with is to sort of hardcode a minor->major map in our setup.py, so the build works sort of like this

• Get m.n.p from protoc
• m' = 3 if n < 21 else 4
• Depend on protobuf>=m'.n,<m'n+1

But this means hardcoding these major version jumps.

[tilsche]

Superseded by #144