`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.

[traversaro]

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

The problem of doing that is that you would not permit to get the latest packages from conda-forge, both involving latest features (that for ML packages like PyTorch are quite essential) or bug fixes (as mentioned in #135 (comment)), including bug fixes that frequently are required to build the robostack packages themself.

I see how this has downsides w.r.t. to the model of ROS distributions build on top of stable distributions, but the hard problem in a context like robostack is that (as far as I know) there is no conda-forge-like distros with stable releases.

[gavanderhoorn]

I'm not claiming it's a solution to the problem / challenges described by @VRichardJP.

Just added a data-point describing why an 'end user' might do what is suggested, as it's the 'easiest' way to get behaviour of tools similar / identical to what is available when working with a version of ROS distributed via the ROS package repositories.

Whether it's acceptable in a particular situation / workspace / environment would have to be determined by the developer/user.

[traversaro]

I'm not claiming it's a solution to the problem / challenges described by @VRichardJP.

Just added a data-point describing why an 'end user' might do what is suggested, as it's the 'easiest' way to get behaviour of tools similar / identical to what is available when working with a version of ROS distributed via the ROS package repositories.

Whether it's acceptable in a particular situation / workspace / environment would have to be determined by the developer/user.

Sure, but I noticed nobody replied for months, and I did not want to give the impressions we are just not sympathetic to requests to "get behaviour of tools similar / identical to what is available when working with a version of ROS distributed" . Personally I am sympathetic to that, but that is antithetic to other useful features of RoboStack, that is be able to use the latest version of dependencies. Building something like that, i.e. robostack-stable and conda-forge-stable would be something interesting, but building something kind different from the existing robostack-stable and conda-forge-stable. I would be really happy if something builds something like that, or volunteers to build something similar under the robostack umbrella.