Enable Python Bindings

[azeey]

The Gazebo vendor packages are currently built with Python bindings disabled. Before enabling, we should figure out how to provide Python shims so that the versionless Gazebo Python modules can be imported.

Perhaps, something like:

from gz-vendor import sdformat
from gz-vendor import math

[jtaveau]

Hey @azeey, do you have any timelines on that?

I just went through this thread, and wanted to know a bit more about it, I'm having exactly the same issue using Jazzy/Harmonic

[HDenial]

ive been having problems with getting the OSRF VRX Project running on Jazzy because of this.

[j-rivero]

Some thoughts on this:

1. For the existing installations that require the Python bindings: a possible workaround could be to use the packages.o.o repository and install the corresponding Python .deb package (i.e: if using ROS Jazzy requiring the Python bindings for sdformat16, install packages.osrfoundation.org repository and use apt-get install sdformat16-python). That would install the sdformat libs in the system together with the same libraries present in the ROS workspace, ABI should be compatible if not fully the same.
2. There is an ongoing change in Proposal: remove major version number from gazebo package names release-tools#1244 to remove the major version numbers (in the upcoming release Gazebo Jetty) from the Gazebo libs that can potentially affect how we want to use them from the ROS vendor packages. We might not need the the shim layer anymore and just use import gz-foo (i.e import sdformat).
3. Under the changes in 2. we might want to consider how we want to proceed with existing ROS distributions not shipping Gazebo Jetty but having Gazebo ROS packages (Jazzy and Kilted at least). Introducing a new level of indirection that is going to be removed soon might be not the best approach.

[scpeters]

The work in gazebo-tooling/release-tools#1244 has been completed for the Gazebo Jetty nightly builds, which will enable import gz.math and import sdformat for Jetty (presumably with ROS L).

We still need to identify what to do for Jazzy and Kilted.

[scpeters]

We still need to identify what to do for Jazzy and Kilted.

The initial suggestion by @azeey seems reasonable to me as a workaround for existing distributions:

from gz-vendor import sdformat
from gz-vendor import math

in ROS L, these could be migrated to

import sdformat
from gz import math

[scpeters]

We still need to identify what to do for Jazzy and Kilted.

The initial suggestion by @azeey seems reasonable to me as a workaround for existing distributions:

from gz-vendor import sdformat
from gz-vendor import math

in ROS L, these could be migrated to

import sdformat
from gz import math

After discussing a bit at today's Gazebo PMC meeting, I changed my mind a bit. Instead of from gz-vendor, I think we could patch the existing vendor patches to provide python bindings without version numbers (from gz import math or import gz.math) for the following reasons:

• we have already removed version numbers in Jetty, so this will avoid the ROS L migration step
• we put in all the effort to remove version numbers from the vendor packages, so it would be counterintuitive to add them to the python bindings

The trade-off with this python scripts using the vendored Harmonic / Ionic would not be compatible with upstream Harmonic / Ionic (which still have version numbers). I'm guessing this is a smaller number of people, and it can be worked around in the short term.

[j-rivero]

Thanks Steve for the summary.

The trade-off with this python scripts using the vendored Harmonic / Ionic would not be compatible with upstream Harmonic / Ionic (which still have version numbers).

I'm not 100% in boat of having incompatible code written for Harmonic that depends on the way of installing the Gazebo pacakges. That would prevent people from transparently changing the installation way and make that trying to reuse other people's code in your code just don't work even if it is totally correct causing confusion in the user.

A possible workaround would be to offer in the existing ROS Gazebo packages both options, so people can use:

import sdformat
from gz import math

and/or

import sdformat15
from gz import math7

not sure about the technical details but should be a matter of providing two file system paths. Could that work or it introduces even more confusion?

[j-rivero]

A possible workaround would be to offer in the existing ROS Gazebo packages both options, so people can use:

Made a prototype in sdformat to generate Harmonic sdf14 Python bindings versioned (as they are now) and unversioned by passing a flag (GENERATE_PYTHON_BINDING_UNVERSIONED):

• Code changes are easy for sdformat.
• The sdformat_vendor package just needs to add that flag and remove the SKIP_PYTHON_BINDINGS.

With this, we are generating two cpython files for a versioned and unversioned bindings.

For this kind of workaround to be applied in Jazzy and for the new Python modules coming in Rolling with Jetty: I just notice that we probably need to adapt our code to place the bindings under the ROS expected subdirectory (most likely /opt/ros/${DISTRO}/lib/python3.xx/site-packages/). In ROS this is obtained using an ament_python call to get PYTHON_INSTALL_DIR.