ROS: How to deal with the package naming of source build ros packages

[ruben-arts]

TL;DR: Should we prefix the package names with ros-<distro>- or not?

Current behavior

We currently always prefix a package name that we can find in the provided ROS Distro with ros-<distro>-. We did this as Pixi then understands that it has to use the local package and not redownload it from the robostack channel.

Problem

This introduces some issues, what if there is a package in the package.xml that is not in the distro and not in the robostack.yaml?
We currently just say, that is not a package we know, use the same name in the dependencies.

For example, this is an issue in trying to convert https://github.com/ros-navigation/navigation2.
navigation2 depends on nav2_ros_common which is not yet in the jazzy distro (might never be, but that is not the point).
Because it's a ROS package, the backend will prefix it with the ros-<distro> on building it, but the packages that depend on it will not be able to resolve the name as a ROS package as it can't be found in the distro.

Thus, with the current setup, we can not build the workspace.

Solution ideas

• We could add configuration to the [workspace] or [package] where you can define a custom map of some sorts to extend the mapping logic of the backend. But this would be a burden to understand and use.
• We could not prefix the packages with the distro and do the distro specification through a dependency on a mutex package that defines the distro, but that would require a rebuild of RoboStack to also use that logic and would avoid users from installing multiple distro's at the same time in one environment.

[traversaro]

I am not sure I understand the problem. Focusing on the navigation2 example, if nav2_ros2_common is built from source, I imagine that the package that it will be creates would be called ros-<distro>-nav2-ros2-common, so with the proper prefix. What is the problem?

[Tobias-Fischer]

Also note that we already have a mutex package in RoboStack if that helps

[daenny]

Related to this, I added this PR:
#359

We have our own packages hosted in our own channels. This allows us to define a custom package_map.yaml such that we can still use pixi build and add custom mappings to find and resolve the names.

[tdejager]

@ruben-arts can you check if what Daniel added is enough to close this issue :)?

[ruben-arts]

With @daenny's feature, the main problem is resolved, but I Imagine it will still be an issue with the UX. I'll keep an eye out on how this progresses and close the issue for now.

[baszalmstra]

As far as I understand the situation now, you have to both add a dependency on your workspace packages in the pixi.toml and add each packages to the mapping. I think that UI is not intuitive at all.

Can we reopen this issue?

[baszalmstra]

I propose we do the following:

Any dependency specified in the package.xml we by default prefix with ros-distro-. E.g. we consider any dependency from that file as a ros package.

If there exists a mapping for the package to a conda name (from robostack.yml or user specified mapping) we use that instead.

Overriding a source package is then simply a matter of doing:

[package.host-dependencies]
ros-noetic-my-pkg = { path = “../my-pkg” }

The only difference with the current behavior is that packages that are not in a mapping are prefixed instead of not prefixed.

I think this is more semantically correct. Dependencies in the package.xml are ros packages. If a dependency in the package.xml is not a ros package (and thus shouldnt be prefixed) you must provide a mapping.

[daenny]

I think this is a fine addition. However, as a side note, I think you need to overwrite it in every section at the moment otherwise it will still look for a condo package.