Add RoboPlan packages

[sea-bass]

Adding roboplan and roboplan-ros repos, version 0.7.0, which fixes the conda vs. ROS build farm ABI incompatibilities and therefore lets us keep dummy packages from conda-forge for the roboplan repo.

Closes #16

[sea-bass]

linux-64 failure here is due to the failure in https://github.com/RoboStack/ros-lyrical/actions/runs/34697655822

[traversaro]

Can I kill the jobs? They are starving the actual rebuilds jobs, and actually building all the packages and not the roboplan one.

[sea-bass]

Yes, please kill as needed!

[sea-bass]

gah I need to make sure the Windows versions get the dlfcn-win32 dependency since the conda-forge version was taking care of that for us, one moment please

[traversaro]

I am not really sold on not using the conda-forge packages here, it seems to me that we are just increasing the chances of ABI conflicts. I will comment more on this tomorrow.

[sea-bass]

The problem is that there are also ROS wrapper packages on top that are not on conda-forge and need to be ABI compatible.

open-planning/roboplan-ros#68

And older distros of ROS depend on nanobind versions that don't have the stable ABI feature.

I guess we could use patches on the roboplan-ros packages?

[traversaro]

Ok, I opened conda-forge/nanobind-feedstock#50 upstream for a long term solution.

For the short term, one thing we need for sure is to add a nanobind-abi host dependency in roboplan's recipe.yaml in roboplan-feedstock , and also add it as a dependency in roboplan-ros , either in patches/dependencies.yaml, and/or in the nanobind rosdep key (I could not find any) at the moment. This solves the problem of mixing different nanobind versions.

To solve stable vs non-stable, to have a simple solution can't we just have a CMake option that we can set in pkg_additional_info.yaml's additional_cmake_args to select whatever we are using in roboplan's conda-forge package?

[traversaro]

I am just suggesting this to avoid even more confusing ABI errors when people (or agent) inevitably will mix roboplan from conda-forge and ros2-roboplan from robostack.

[sea-bass]

the nanobind rosdep key (I could not find any) at the moment.

It's nanobind-dev: https://github.com/ros/rosdistro/blob/fdd040e91503dfdcac6138e6b01449df72249df0/rosdep/base.yaml#L8612

[traversaro]

the nanobind rosdep key (I could not find any) at the moment.

It's nanobind-dev: https://github.com/ros/rosdistro/blob/fdd040e91503dfdcac6138e6b01449df72249df0/rosdep/base.yaml#L8612

Ack, then we should add nanobind-dev: [nanobind, nanobind-abi] in https://github.com/RoboStack/ros-lyrical/blob/main/robostack.yaml .

[sea-bass]

All clear on the first parts.

On the last part about the CMake arg, you mean some option in roboplan-ros that removes this inconsistency by adding OPTIONAL_COMPONENTS Development.SABIModule?

open-planning/roboplan-ros#68 (comment)

[traversaro]

All clear on the first parts.

On the last part about the CMake arg, you mean some option in roboplan-ros that removes this inconsistency by adding OPTIONAL_COMPONENTS Development.SABIModule?

open-planning/roboplan-ros#68 (comment)

I guess what changes the type of module is STABLE_ABI passed to nanobind_add_module in https://github.com/open-planning/roboplan/blob/main/roboplan_core/bindings/CMakeLists.txt#L93, right? Or is STABLE_ABI silently ignored somehow here?

[sea-bass]

It's likely that it's silently ignored (or with a warning that we're not seeing).

I think that we're observing is that if you take roboplan from its conda-forge package, you're seeing the else() case in here:

https://github.com/open-planning/roboplan/blob/eac8ca779dce417d0b280930530ba905d29c7b23/roboplan_core/bindings/CMakeLists.txt#L28-L31

which probably makes the STABLE_ABI kick in correctly here.

---

however, in the roboplan-ros repo we don't have such an if-else structure:

https://github.com/open-planning/roboplan-ros/blob/2f45e58533c6d3a25f4f664b0fb29ae09b6e98d5/roboplan_ros_cpp/bindings/CMakeLists.txt#L4

so even though we are using STABLE_ABI in e.g. here (https://github.com/open-planning/roboplan-ros/blob/2f45e58533c6d3a25f4f664b0fb29ae09b6e98d5/roboplan_ros_cpp/bindings/CMakeLists.txt#L23), maybe that part is being ignored?

[sea-bass]

@traversaro As an update here, we took the CMake route and added CI jobs for testing mix/match conda-forge roboplan + ament built roboplan-ros: open-planning/roboplan-ros#69

I'll revisit this PR when we cut the 0.7.0 releases.

[traversaro]

@traversaro As an update here, we took the CMake route and added CI jobs for testing mix/match conda-forge roboplan + ament built roboplan-ros: open-planning/roboplan-ros#69

I'll revisit this PR when we cut the 0.7.0 releases.

Great, thanks!

[sea-bass]

@traversaro I updated to the new RoboPlan 0.7.0 packages, which means we can keep the conda-forge dummy packages for the core roboplan repo.

Not sure how correctly I did this, but it works locally and CI seems good. Looking forward to your feedback, and if this works out I can work on rolling this out to the other distros.

[sea-bass]

idk why this updated, maybe just because I have the latest pixi version locally?

[traversaro]

Yes, I think it is fine.

[traversaro]

Not sure how correctly I did this, but it works locally and CI seems good. Looking forward to your feedback, and if this works out I can work on rolling this out to the other distros.

In general the rosdistro_snapshot.yaml is not meant to be updated, but as in this we only touched packages that were not released before, we do not risk any ABI regression.