Add recipes for zenoh, zenoh-c and zenoh-plugin-webserver

[traversaro]

Fix #26053 .

PR content

This PRs adds some initial recipes for Zenoh ecosystem (https://zenoh.io/).

In particular, it contains the following recipes that generate the following packages (structure and naming inspired by the Debian and homebrew existing packages):

• zenoh recipe, corresponding to the https://github.com/eclipse-zenoh/zenoh repo, that generates the packages:
  • zenoh-rust-abi, meta-package that captures the Rust ABI used by zenohd and all the Rust plugins
  • zenohd, containing the zenohd zenoh router executable
  • zenoh-plugin-rest, rust plugin that is dlopen-ed by zenohd
  • zenoh-plugin-storage-manager, rust plugin that is dlopen-ed by zenohd
  • zenoh, metapackage that depends on zenohd, zenoh-plugin-rest and zenoh-plugin-storage-manager for consistency with the equivalent package available for Debian and homebrew
• zenoh-c recipe, corresponding to the https://github.com/eclipse-zenoh/zenoh-c repo, that generates the packages:
  • libzenohc package, containing a C library implemented using rust
• zenoh-plugin-webserver recipe, corresponding to the https://github.com/eclipse-zenoh/zenoh-plugin-webserver repo, that generates the packages:
  • zenoh-plugin-webserver, rust plugin that is dlopen-ed by zenohd

I typically avoid to include multiple recipes in the same PR, but in this case this is useful to show how future zenoh-* packages may be packaged.

Zenoh specificity

The most important thing is to distinguish two kind of zenoh packages:

• Packages that uses rust to build executables, or libraries that only expose a C/C++/Python interface: these packages can be built as other rust-based packages in conda-forge.
• Packages that create rust dynamics libraries that are loaded by zenohd (that typically are named zenoh-plugin-* or zenoh-backend-*). These packages need special care as they need to be compiled using exactly the same dependencies and rust compiler version used to compile zenohd, as otherwise ABI breakage could happen (see https://github.com/eclipse-zenoh/zenoh/tree/0.11.0?tab=readme-ov-file#plugins). The fact that all plugins of a given zenoh version are built with the same packages of the same release zenohd is ensured by the Cargo.lock files in zenoh repositories, that are appropriately aligned (see for example eclipse-zenoh/zenoh-plugin-webserver@ec23805). So to ensure that all zenohd and zenoh plugins installed in the same environment are compatible, we created the zenoh-rust-abi package on which zenohd and all zenoh plugins depend. The version of zenoh-rust-abi is defined as {{ zenoh_version }}.{{ rust_compiler_version }}, ensuring that if necessary a given zenoh release can be compiled for a newer rust compiler version.

An example of the first kind of package is libzenohc contained in this PR, it has a run dependency on zenoh-rust-abi, but just to ensure that libzenohc is installed with a zenohd with the same version:

  run:
    - zenoh-rust-abi {{ version }}.*

On anothe hand, an example of the second kind of package is zenoh-plugin-webserver, that needs to match the ABI that zenohd expects, and so has the following constraint on zenoh-rust-abi:

  host:
    - zenoh-rust-abi {{ version }}.{{ rust_compiler_version }}

(the hosts dependency becomes a run dependency thanks to zenoh-rust-abi's run_exports.

Alternatives considered

Possible modifications to the packaging strategies that I considered but eventually did not do:

• To avoid to have to manually bump the rust version used in all the packages, I considered that we could build all the zenoh packages that need to share the same rust abi (so basically zenohd and all the zenoh-plugin-* and zenoh-backend-* packages) in the same recipe/feedstock. I excluded this in the end as there are many such packages (see https://github.com/search?q=org%3Aeclipse-zenoh+zenoh-plugin&type=repositories and https://github.com/search?q=org%3Aeclipse-zenoh+zenoh-backend&type=repositories) and so it would be eventually be difficult to manage all of them in a single feedstock.
• I tried to avoid hardcoding the rust_compiler_version in conda_build_config.yaml, but without that I was unable to use the {{ rust_compiler_version }} in the recipes, so I found no other solution to be able to compute the version of the zenoh-rust-abi.

Checklist

• Title of this PR is meaningful: e.g. "Adding my_nifty_package", not "updated meta.yaml".
• License file is packaged (see here for an example).
• Source is from official source.
• Package does not vendor other packages. (If a package uses the source of another package, they should be separate packages or the licenses of all packages need to be packaged).
• If static libraries are linked in, the license of the static library is packaged.
• Package does not ship static libraries. If static libraries are needed, follow CFEP-18.
• Build number is 0.
• A tarball (url) rather than a repo (e.g. git_url) is used in your recipe (see here for more details).
• GitHub users listed in the maintainer section have posted a comment confirming they are willing to be listed there.
• When in trouble, please check our knowledge base documentation before pinging a team.

[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 (recipes/zenoh) and found it was in an excellent condition.

I do have some suggestions for making it better though...

For recipes/zenoh:

• This recipe is using a compiler, which now requires adding a build dependence on {{ stdlib("c") }} as well. Note that this rule applies to each output of the recipe using a compiler. For further details, please see META: {{ stdlib("c") }} migration conda-forge.github.io#2102.

[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 (recipes/zenoh) and found it was in an excellent condition.

[conda-forge-webservices]

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

I wanted to let you know that I linted all conda-recipes in your PR (recipes/zenoh, recipes/zenoh-c, recipes/zenoh-plugin-webserver) and found some lint.

Here's what I've got...

For recipes/zenoh-c:

• There are too few lines. There should be one empty line at the end of the file.

For recipes/zenoh-plugin-webserver:

• There are too few lines. There should be one empty line at the end of the file.

[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 (recipes/zenoh, recipes/zenoh-c, recipes/zenoh-plugin-webserver) and found it was in an excellent condition.

[traversaro]

The recipe is ready for review, thanks! Note that the CI already passed, the CI restarted as I squashed a lot of commits. @conda-forge/help-c-cpp @conda-forge/help-rust @conda-forge/staged-recipes

[github-actions]

To help direct your pull request to the best reviewers, please mention a topic-specifc team if your recipe matches any of the following: conda-forge/help-c-cpp, conda-forge/help-cdts, conda-forge/help-go, conda-forge/help-java, conda-forge/help-julia, conda-forge/help-nodejs, conda-forge/help-perl, conda-forge/help-python, conda-forge/help-python-c, conda-forge/help-r, conda-forge/help-ruby,or conda-forge/help-rust. Thanks!

[xhochy]

Not sure what the error was but one likely thing could be that in the first pass over the recipe conda-smithy does not yet have a value for it. You could work around this by setting it to something at the top of the recipe if not set yet.

[xhochy]

The one comment is probably better addressed in a feedstock where you get more detailed rerender error messages.

[traversaro]

The one comment is probably better addressed in a feedstock where you get more detailed rerender error messages.

Exactly, that was my plan. Thanks for the review!