ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A

Experimental Python package index for ROS

Hi, Python ROS users!

I’d like to introduce an experimental python package index which hosts basic ROS Python packages that can run without ROS installation.
This enables to

  • try ROS(rospy) in a Python way such as a virtualenv&pip
  • easily integrate ROS with an existing Python project

You can try ropy as follows:

virtualenv -p python3 venv
source venv/bin/activate
pip install --extra-index-url rospy-all

Most of the packages are written in pure Python, so they can be installed into multi platforms and also Python 3 environment.
A few packages(tf2_py and PyKDL) which need to be built with a c++ library are offered also as binary wheels(only Linux and OSX), you don’ t need to build them by yourself.

All packages are built by a script in this repo.

Please enjoy and any feedback is welcome!



This looks super useful. I wish this was around when I needed a Ros free version of TF2 (though that need led to

Why not put the packages on the actually PyPI?

@otamachan This is great to see. Thanks for sharing. If you’d like to pursue it further I’d suggest looking at if it can integrate with Superflore which supports generating indexes of packages for different platforms. A pypi index could be another platform onto which to extend support.

I think that the private python index is more appropriate for this until it’s a more formalized effort. If you put something on PyPi it should be a commitment to maintaining it. And there’s also likely a lot of potential naming collision and name grabbing if you automatically post all of these.

That’s a fair point. I do like the idea of a ROS/ROS2 python package index. I think it would fix a number of my pain points. Open to help as needed. @otamachan if you would like help with the Superflore integration if that’s something you’re interested in please hit me up.


Thank you very much for your feedbacks @safijari, @tfoote !

I didn’t know Superflore and I found it interesting to integrate with it.
I will take a deeper look and try something.

1 Like

Great job @otamachan! I would also be down to help if you needed any. :slightly_smiling_face:


Hi @otamachan, cool initiative!

I have been working on getting ROS packages on conda/conda-forge. This is like pip + virtualenv but on steroids, and works for native packages as well. There are many benefits that I mention in my blog post:

Maybe we can join forces somehow? I would be happy to get more contributors to this adventure :slight_smile:

1 Like

Being a primarily pip/virtualenv user with a passing interest in Conda, I’d like to see both paths pursued, ideally with common build strategies. I’m very interested in helping with such an effort

I understand the need to run separated package management tools for everything that runs inside ROS, to keep a tight control on it, but a python package that is detached from ROS releases should not go into any ROS-specific package manager, it needs to go to pypi (and then also conda-forge for convenience).

Regarding the commitment to maintain it, I agree it is a must, but I also think it’s not so difficult to commit to that: at least, on my side, I offer to help with maintenance if this package moves into proper distribution channels. I am currently the maintainer of roslibpy, which we developed exactly for the purpose of using ROS from outside ROS in Python, so, I’d gladly support this effort as well.

EDIT: corrected pypi instead of pip

I assume by pip you mean pypi. I both agree and disagree. I think it’s fine to put such packages on pypi, but if they get put on another index I think that’s ok too. The user would simply need to edit their .conf/pip/pip.conf to ensure that the new index gets searched as well (which you could provide a script for),very similar to how the apt source is added.

Correct, I meant pypi, I fixed it.

I think you’re answer doesn’t quite answer the point. It is clearly possible to also upload it to another index, it’s also possible to pip-install it directly from git for that matter, and from a zip file on a website, and probably a number of other exotic means. The point I’m trying to make is that, the default way of installation should be the default package index of the python community, ie pypi; any non-standard steps to installation will lead to less adoption.