Support more protobuf versions in GitHub workflow

[ClemensLinnhoff]

Reference to a related issue in the repository

#765

Add a description

Fix pipeline behavior with different protobuf versions

Take this checklist as orientation for yourself, if this PR is ready for the Change Control Board:

• My suggestion follows the style and contributors guidelines.
• I have taken care about the message documentation and the fields and enums documentation.
• I have done the DCO signoff.
• My changes generate no errors when passing CI tests.
• I have successfully implemented and tested my fix/feature locally.
• Appropriate reviewer(s) are assigned.

If you can’t check all of them, please explain why.
If all boxes are checked or commented and you have achieved at least one positive review, you can assign the label ReadyForCCBReview!

[ClemensLinnhoff]

Protobuf 2.6.1 does not work out of the box, since it does not have '-all' in the link/package:
https://github.com/OpenSimulationInterface/open-simulation-interface/actions/runs/7609941012

If '-all' is changed to '', it will download abseil, but cannot install it, since protobuf 2.6.1 has autotools (configure). So the if condition distinguishing between autotools and cmake is not correct:
https://github.com/OpenSimulationInterface/open-simulation-interface/actions/runs/7609969004

Also, between 3.0.0 and 3.5.0 there is no package for all environments.

[ClemensLinnhoff]

With my changes, protobuf 2.6.1 can be installed. But now installing python fails:
https://github.com/OpenSimulationInterface/open-simulation-interface/actions/runs/7610124644

[ClemensLinnhoff]

I now managed to get the setup.py to work with protobuf 2.6.1. However, now a unit test fails. Apparently Protobuf 2.6.1 does not support Python 3...

My recommendation: Let's set the minimum proto version to 3.0.0, as it already says in the documentation anyways.

[pmai]

I now managed to get the setup.py to work with protobuf 2.6.1. However, now a unit test fails. Apparently Protobuf 2.6.1 does not support Python 3...

My recommendation: Let's set the minimum proto version to 3.0.0, as it already says in the documentation anyways.

At least officially protobuf states Python 3 support since 2.6.0... The error logs look more like there are changes in the location of the bundled proto include?

[jdsika]

I now managed to get the setup.py to work with protobuf 2.6.1. However, now a unit test fails. Apparently Protobuf 2.6.1 does not support Python 3...
My recommendation: Let's set the minimum proto version to 3.0.0, as it already says in the documentation anyways.

At least officially protobuf states Python 3 support since 2.6.0... The error logs look more like there are changes in the location of the bundled proto include?

What about this here? protocolbuffers/protobuf#882

[jdsika]

Considerations:

• IF protobuffer min. version is set to >3.0.0 THEN we should switch to proto3 syntax
• Remove proto 2to3 converter
• Remove second build step
• check flatc compatibility with proto3 syntax

[jdsika]

@ClemensLinnhoff and @pmai this PR must be closed and we have to check if there is anything missing. See also my questions above. I think we are still inconsistent as the docs still mention proto version >3.0.0 and then my questions with the proto syntax arise!

[ClemensLinnhoff]

Python is now completely decoupled from the protobuf version. So the changes to setup.py are superseded.
What is the status on proto 2 support for C++? Then we might need the changes. However, only the CI pipeline has minor changes.

[pmai]

Since this only affects our internal build pipeline, and we have no direct necessity to always build against multiple protobuf versions (we have not had any regressions due to PB changes, only our build pipeline is ever affected), I think this change is not release relevant, and we should look at this more carefully after the release (i.e. what really are our needs here, and how do we want to structure this; the past CI improvements were more for moving forwards). The danger that we inadvertantly blow up some part of the build or release process seems paramount.