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