Package request: zenoh-related packages

[traversaro]

Package name

zenoh

Package version

Newest

Package website

1. https://zenoh.io/
2. https://github.com/eclipse-zenoh/zenoh-python (Python library, binding of zenoh Rust library)
3. https://github.com/eclipse-zenoh/zenoh (zenohd executable, using zenoh Rust library)
4. https://github.com/eclipse-zenoh/zenoh-c (zenoh C library, bindings of the zenoh Rust library)
5. https://github.com/eclipse-zenoh/zenoh-cpp (zenoh C++ library, header-only C++ libraries that wraps the zenoh-c library with C++ friendly functionality)

Package availability

1. https://pypi.org/project/eclipse-zenoh/
2. https://download.eclipse.org/zenoh/debian-repo/
3. https://github.com/eclipse-zenoh/homebrew-zenoh

Additional comments

This package is similar to other C++/Python bindings of a Rust library, so the observations of #23725 and conda-forge/rerun-sdk-feedstock#18 also apply here.

Package is not available

• The package is not available on conda-forge.

No previous issues or open PRs

• No previous issue exists and no PR has been opened.

[traversaro]

The project had custom apt packages (https://download.eclipse.org/zenoh/debian-repo/), that we can take as inspiration for the names of the libraries:

• zenohd : zenoh router executable
• libzenoh-c : C library
• libzenoh-cpp : C++ library

I have just some doubts on the name of the python library. The python module name and the PyPI name is eclipse-zenoh, however it seems strange to use eclipse in the name of the library only in Python, while do not have it in the rest of the package names. However, have the same name in conda-forge and PyPI is also quite convenient, so it may be just easier to have the python package name simply called eclipse-zenoh.

[traversaro]

Note that there may be some tricky aspects related to zenohd and its plugin packaging:

As Rust doesn't have a stable ABI, the plugins should be built with the exact same Rust version than zenohd, and using for zenoh dependency the same version (or commit number) than 'zenohd'. Otherwise, incompatibilities in memory mapping of shared types between zenohd and the library can lead to a "SIGSEV" crash.

For the time being, my goal is just to have libzenoh-c and libzenoh-cpp, that anyhow can be used in peer2peer mode without the use of zenohd, so I will concentrate on package first libzenoh-c and then libzenoh-cpp.