Ros-python-wheels: pip-installable ROS 2 packages

ROS ROS General
, , ,
1

Hello ROS community,

I’d like to share that I’ve been working on making ROS 2 packages pip-installable with a project called ros-python-wheels! Furthermore, a select number of ROS packages are made available on a Python package index which I’ve hosted at Cloudsmith.io

Getting started with ROS 2 in Python is as simple as running:

pip install --extra-index-url https://dl.cloudsmith.io/public/ros-python-wheels/kilted/python/simple ros-rclpy[fastrtps]

Key Benefits

This enable a first-class developer experience when working with ROS in Python projects:

  • Easy Project Integration: To include the ROS Python Client (rclpy) in a Python project, simply add ros-rclpy[fastrtps] with its package repository to your pyproject.toml file.

  • Enable Modern Python Tooling: Easily manage Python ROS dependencies using modern Python tools like uv and Poetry.

  • Lightweight: The wheels of rclpy all of its dependencies have a total size of around 15MB.

  • Portable: Allows ROS to be run on different Linux distributions.

Comparison

This approach provides a distinct alternative to existing solutions:

  • In comparison to RoboStack, wheels are more lightweight and flexible than conda packages.
  • rospypi is a similar approach for ROS 1, whereas ros-python-wheels targets ROS 2.

I’d love to hear your thoughts on this project. I’d also appreciate a star on my project if you find this useful or if you think this is a good direction for ROS!

2

Hmm, this is interesting :slight_smile:

Unfortunately, not even common_interfaces are part of the distro. So while you can communicate, the amount of message types you can use seems to be limited to the builtin interfaces, right?

Also, I guess it cannot install any system-level (apt/dnf) dependencies, right? So the possible set of packages releasable this way seems also to be much narrower than in the conda case.

Last, what is the role of the c and cpp typesupport packages in your distro if it only runs on Python?

3

Thanks for taking a look at the project!

common_interfaces and other messages interfaces will be added soon, I just got the initial prototype working.

I think it’s possible to build a wheel of any system-level dependency by packaging up the shared libraries. After all, if Pytorch, Tensorflow, and CUDA all have wheels that are independent of any system-level dependency, then why not ROS?

c and cpp typesupport packages are needed by the C++ libraries that the Python layer binds to.

2 Likes
4

common_interfaces has been added!

1 Like
5

I’m curious what you mean when you say wheels are more lightweight than conda packages? Conda packages are just metadata around the built packages?

i know there is an initiative within py org for next gen wheels to deal with a lot of the complex system dependencies and their variants as they are not really supported properly at the moment

6

Sorry yeah that was an inaccurate general statement by me. In this specific case, wheels are lighter weight than conda and debian packages since they don’t need to include cmake and environment setup files (there’s about 15 of those files for ros-jazzy-rclpy for example).

The next gen wheels that deal with system dependencies sounds interested, do you have any more details on that?

7

Thanks for sharing the project, it is really interesting and useful in context where PyPI packages are required!

Portable: Allows ROS to be run on different Linux distributions.

It seems that the current approach is repackaging existing binaries from the official binaries, so I guess the “different Linux distribution” do need to at least have a glibc and libstdcxx of the same version or newer of the corresponding apt distribution?

Just a curiosity, I see that you are not using auditwheel that is typically used in these kind of binary repacking, there is a specific reason for not using it?

The next gen wheels that deal with system dependencies sounds interested, do you have any more details on that?

The general initiative can be found at https://wheelnext.dev/ .

Interesting contents can be found in native_lib_loader library, see Native-lib-loader: Documentation and best practices on using native libraries in Python wheels - Packaging - Discussions on Python.org for an in-depth discussion, even if I am afraid that method is not really suitable for the ROS case, but I would be happy to be proven wrong.

It is not directly a WheelNext initiative, but I think in this context also PEP 725 is quite interesting, also as it has an interesting overlap with rosdep.

In comparison to RoboStack, wheels are more lightweight and flexible than conda packages.

Just to understand, in which sense the provided wheels are more flexible then conda packages? Full disclaimer: I am one of the RoboStack mantainers.

By the way, I think also Nvidia is providing ROS 2 installable as wheel as part of the isaacsim installation, it would be interesting to hear a comparison between the two approaches.

2 Likes
8

That’s correct. I do want to explore actually building the binaries for different platforms as one of the next steps after this initial proof-of-concept. I tried using auditwheel but ran into some issues (which I’ve already forgotten), I may revisit this again.

A couple of key flexibilities are:

  • You can use any package manager including uv which is very popular right now, instead of needing to use some variant of conda.
  • If any project that’s available on PyPI wants to specify some ROS packages as dependencies, it can do that.

RoboStack remains the best way to easily install ROS with full functionality! Whereas right now the Python wheels are best for lightweight Python-based ROS integrations where you don’t need node launching or building of C++ nodes.

Thanks for all the other great information in your post, particularly how NVidia has made ROS installable as wheel! I will dig into those and report back.

1 Like
9

Note using pixi for robostack (in my opinion) greatly improves the package management experience, and it uses uv under the hood for wheels

2 Likes