Investigate using python bindings of sdformat instead of the gz command line

[diegoferigo]

Starting from version 13, sdformat introduced native Python bindings. It's worth investigating if we could just call this library (that depends only on sdformat) instead of requiring to find the entire Gazebo Classic or Gazebo Sim suite.

Few comments:

• I could not find any package in PyPI nor conda-forge, last time I tried I think I installed it from the OSRF repo.
• Relevant discussion in Add lxml dependency jaxsim#89 (comment)

[traversaro]

I could not find any package in PyPI nor conda-forge, last time I tried I think I installed it from the OSRF repo.

There is indeed no package on PyPI. On conda-forge the package are sdformat13-python and sdformat14-python, see https://github.com/conda-forge/libsdformat-feedstock and ami-iit/jaxsim#89 (comment) .

[diegoferigo]

Excellent, maybe instead of replacing the usage of gz|ign command line, we can first try to import sdformatXX and, if not found, use the existing logic that exploits the full Gazebo installation.

In this way, we can slim down significantly our conda environments that install a full Gazebo suite just for having gz sdf.

[traversaro]

Excellent, maybe instead of replacing the usage of gz|ign command line, we can first try to import sdformatXX and, if not found, use the existing logic that exploits the full Gazebo installation.

In this way, we can slim down significantly our conda environments that install a full Gazebo suite just for having gz sdf.

Yes, that probably gets the best of both worlds, all dependencies installed in conda-forge while the possibility still of installing the library via pip by relying on gz installed in the system.

[diegoferigo]

Referring #34 (comment), we managed to perform the URDF to SDF conversion by only requiring sdformat and gz-tools. I had early attempts of using the Python bindings of sdformat, but I couldn't find any way to catch the stdout produced when the conversion fails. For unknown reasons, the usual Python pipes to redirect the output do not catch the failures.

I'll leave this issue open as help wanted in case someone wants to try again (and I mean, using the python bindings as alternative method not as replacement). In the meantime, I can live happy by calling gz sdf.

[traversaro]

Not directly related to this issue, but on the topic of supporting URDF --> SDF conversions when rod is installed via pypi . After gazebosim/sdformat#1489, the gz-sdf will not be using ruby anymore, but it will be a "regular" C++ executable. So in theory we could be a fully statically linked executable of gz-sdf (for example using vcpkg), and ship it with rod PyPI's wheel. The complexity of setting this up would not be trivial, but I just wanted to mention that with gazebosim/sdformat#1489 this will become an option.

[diegoferigo]

we could be a fully statically linked executable of gz-sdf (for example using vcpkg), and ship it with rod PyPI's wheel

This is a long awaited feature, it would be a great addition to the package!

Beyond vcpkg, another good enough option would be using vcstools + colcon taking as input e.g. sdformat13.yaml.

Something to keep in mind:

• If the binary is vendored in the wheel, the PyPI package would become architecture-dependent and this makes the the CI/CD pipeline way more complicated.
• If the compilation of the binary is handled by the python build backend (e.g. through a CMake-based build extension), the conda-forge recipe should get updated to ignore this new logic and keep relying on the resources installed from the libsdformatXX and gz-toolsX.

All of this is true if a cmake-based build backed is used. The advantage of doing so is that a pip install . would generate automatically a working wheel locally (assuming that the compiler and other build dependencies are found). Alternatively, this operation could be done only in CI/CD just for PyPI such that the resulting binary can be copied into the wheel before uploading it. However, I fear that in this last way, the packaging and naming of architecture-dependent wheels would be more complicated and error prone.

Curiosity, are we sure that the binary is by default standalone? My intuition tells me that the dependent libraries should be compiled as static for that aim.