`ros2-distro-mutex` is not aligned on recommended ubuntu distro libraries?

[VRichardJP]

I am trying out pixi with ROS, and I am running into several issues when building ROS packages because ros2-distro-mutex pulls in much newer library versions than those typically used in native ROS setups.

For example, the recommended distribution for humble is Ubuntu 22.04, where the available libpcl-dev version is 1.12.1. However, ros2-distro-mutex pulls PCL 1.15.1. The same situation applies to the other pinned libraries.

This feels like it introduces unnecessary friction for people trying to build ROS 2 with pixi+robostack. Is there a specific reason for this choice?

[traversaro]

This is indeed a common confusion point (for example, it came out in https://discourse.openrobotics.org/t/pixi-as-a-co-official-way-of-installing-ros-on-linux/51764) so I suspect we should document this somewhere.

Anyhow, the point is that robostack is based on conda-forge, that itself is a rolling release distribution, so we try to be quite aligned with conda-forge ABI pinnings (see https://conda-forge.org/docs/maintainer/pinning_deps/ and https://conda-forge.org/blog/2019/12/06/cfep09/) mainly for two reasons:

• Let's say that we find a bug in a ROS dependency (let's say for example PCL or protobuf). If we use the latest version, we can easily add a patch fixing the bug to the relevant conda-forge feedstock, and use the latest version in robostack right away.
• Using the same pinnings of conda-forge permits us to co-install ROS and latest version of complex to install (tipically GPU-accelerated) libraries (like llama.cpp, pytorch, onnxruntime) easily. If we pinned ROS packages to the older version of shared deps (like protobuf) we would be forced to use really old version of pytorch as well.

Having said that, nothing prevents building ROS or the RoboStack packages with older packages (if they work). This is what upstream ROS is doing in the upstream Windows installation instructions, see:

• https://docs.ros.org/en/kilted/Installation/Windows-Install-Binary.html
• https://github.com/ros2/ros2/blob/rolling/pixi.toml

[VRichardJP]

I understand. Indeed, a small disclaimer would certainly help.

As it has been raised in the discourse discussion already, having such a wide version gap between native and rolling libraries put package users/maintainers in a strange position. On one hand, pixi and robostack are extremely useful to easily create development environments; the catch, however, is that they can't reproduce the native environment end users are meant to be running on.

Regarding robostack itself, how difficult would it be to create a "robostack-humble-stable" (local) channel, which would pin libraries to the same versions as in Ubuntu 22.04? Of course, such channel would not offer bleeding software, but I don't think many ROS project really need the very last release of every dependency they use. On the other hand, I think this would significantly boost adoption of pixi tooling in the ROS community.

Or would this simply be unmaintainable?

[traversaro]

Regarding robostack itself, how difficult would it be to create a "robostack-humble-stable" (local) channel, which would pin libraries to the same versions as in Ubuntu 22.04? Of course, such channel would not offer bleeding software, but I don't think many ROS project really need the very last release of every dependency they use. On the other hand, I think this would significantly boost adoption of pixi tooling in the ROS community.

Or would this simply be unmaintainable?

This is a good question, I always thought it would be too difficult to even get a consistent set of co-installable packages from conda-forge matching more and less the Ubuntu LTS versions of key deps, but I guess the only way to really know it is a prototype.

To give you an idea of the possible challanges, I think it is informative to read the # TODO: comments in https://github.com/ros2/ros2/blob/jazzy/pixi.toml, that may be give you an idea of possible problems.

[gavanderhoorn]

@VRichardJP wrote:

On one hand, pixi and robostack are extremely useful to easily create development environments; the catch, however, is that they can't reproduce the native environment they are meant to be running on.

I'd second this: I often pin things like CMake and sometimes even compiler versions just to avoid having to deal with CMake policies and/or deprecations that ROS packages targetting/supporting a specific ROS release don't take into account (and rightly so: they're supporting a specific ROS version, not my mishmash of bleeding edge stuff in a 'weird' environment).

Helping them fix this is sometimes possible, but if we just want something to work, it's out-of-scope and dealing with it all is too inconvenient.

Pinning dependencies to versions close enough to the versions depended on by a specific ROS release helps tremendously in those cases is my experience.