Dual protobuf

[hmaarrfk]

This would really be helpful for me.

See conda-forge/libprotobuf-feedstock#198 conda-forge/tensorflow-feedstock#378

needless to get my dual opencv builds up and running again:
conda-forge/opencv-feedstock#396

Checklist

• Used a personal fork of the feedstock to propose changes
• Bumped the build number (if the version is unchanged)
• Reset the build number to 0 (if the version changed)
• Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• Ensured the license file is being packaged.

[conda-forge-webservices]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[ilya-lavrenov]

With static probobuf we had no such issues :D

[hmaarrfk]

Tell me about it…..

[hmaarrfk]

anyway, i'm excited to see if we can get the openvino runtime working for onnxruntime. not sure if you have any interest in helping on that front!!!!

(Thats my other plan for getting away from tensorflow)

[ilya-lavrenov]

anyway, i'm excited to see if we can get the openvino runtime working for onnxruntime. not sure if you have any interest in helping on that front!!!!

It's a good plan.
I even have a PR to ONNX Runtime repo for simpler cmake integration microsoft/onnxruntime#19184. Once it's merged and released, we can seamlessly integrate OV and ONNX runtime via find_package(OpenVINO).

I have a commit in conda-forge onnx runtime feedstock ilya-lavrenov/onnxruntime-feedstock@54134c1 which performs such integration.

Do you think we don't need to wait for official ONNX RT releases and can use those patches?

UPDATE: those changes are implemented when protobuf was used as a static library for OpenVINO, so we don't have any issues with compatibility of different protobuf versions

[hmaarrfk]

Lets maybe discuss the static protobuf in the most problematic feedstock.
conda-forge/tensorflow-feedstock#378

Other feedstocks have been quite compatible with conda-forge's dynamic linking strategy so its hard to really point to specific problems that dynamic linking brings other than making it difficult to compile tensorflow.

Do you think we don't need to wait for official ONNX RT releases and can use those patches?

I am much more inclined to merge in a patch that has been

1. submitted upstream
2. Generally accepted as a good idea by upstream
3. is limited to the build process
4. Helps in dynamic linking and unvendoring from downstream feedstocks ;)

This seems to hit all these points.

There is no exact science, but if you are inclined you can try to see how well it applies to 1.17.1 and hopefully you won't have to do so much work.