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

Should we warn (new) users about difficulties with Python 3 and alternative Python interpreters?

tl;dr: should the installation tutorials show a warning about using ROS with anything but vanilla Python 2? Especially on Ubuntu/Debian systems this would seem to avoid a lot of problems with users trying to use Python 3 or alternative interpreters or runtime environments (Anaconda fi).

There are quite a few questions on ROS Answers about issues that ultimately turn out to be caused by the OP having alternative Python interpreters / runtime environments installed (such as Anaconda) or trying to mix in / use Python 3.

Examples of problems are (seemingly) missing modules (rospkg, catkin_pkg, etc), syntax errors and divergent versions of interdependent modules (users setting $PYTHONPATH to the union of their Python 2 and Python 3 dist-packages and site-packages directories). Quite a few of these situations are then ‘rectified’ by doing pip installs of the packages, potentially leading to all sorts of other problems in the future.

Even thought it’s possible to get such setups to work, especially new users seem to run into problems, leading to many posts on ROS Answers. The search apparently doesn’t work too well (or isn’t used at all) and the situation is exacerbated by the fact that these problems can manifest themselves in strange ways that don’t always immediately seem to point to problems with Python.

I didn’t want to immediately start editing the pages, but perhaps adding a clear warning to the installation tutorials could help avoid some of this. There are some answers on ROS Answers that show possible ways of using Python 3 / Anaconda and those could be added to the warning as references for users that would still like to use them.

One thing to consider is whether OS other than Ubuntu/Debian need these warnings: many of the core ROS Python are bilingual already and OS that don’t ship Python 2 any more are exploiting that (Arch fi).


tl;dr: agreed, but it would be nice to have a python3 shadow repository earlier for testing, to prepare for the inevitable switch to python3.

Another option would be to fix some of the underlying issues. I know that there are some challenges to support different python versions in the same binary repo. The alternative is to wait for a distro to switch to pyhton3 as the default and do the same for the ROS repository for that distro.

The only issue with waiting is that it doesn’t really provide a testing period for python3. After all, there’s only 2 to 3 more years of python2 maintenance [1][2]. It would be nice if people could test python3 earlier on Ubuntu (without building from source) so that potential issues will be found before a switch is pretty much forced.

A relatively simple option might be to have another shadow repository built with only python3. There would be no need to differentiate between python2/3 versions of packages then, because there is still only one version in each repository.

Either way, a warning for new users still makes sense (unless dual support in the same repo is provided, but that seems unrealistic). But if there is a semi-supported way for them to use python3, the warning could also point them in the direction of that repo (still with a big warning that it’s experimental of course).

If they do use the python3 repo and still get into issues, it is likely a real issue that should be fixed rather than a problem with their environment.


I believe a discussion around facilitating migration to Python 3 is already taking place in ros-infrastructure/rep#149 (add draft for REP 151 - Python 3 support) and ros-infrastructure/rep#154 (Bilingual Python proposal).


Every time I run a tutorial, there is inevitably someone using Anaconda. That thing messes up your system so badly. ROS isn’t the only Python software I’ve seen not work with it installed.

It’s 2018. I feel it would be best to be pushing python3 as the preferred version. I understand avoiding derivative interpreters but python3 was introduced 10 years ago and the python2.7 is legacy.

Perhaps the group should establish python3 for ROS2. At least it’s a place to make a break and set a forward direction.

Addendum: I have been corrected. ROS2 is using python3.

That’s already been done for ROS 2.

Have you any useful suggestions for how to migrate the huge base of ROS 1 code? Most of it cannot easily be testing with Python 3, yet.

People are working on that, perhaps you could assist?

It’s good that ROS2 has stardardized on python3.

As for ROS[1], support for pyrhon2.7 vs python3 comes down to the package author/owner.

Some package support python3 while sone doesn’t. It’s completely possible to use ROS with python3.

I don’t know if a guaranteed way to correctly notify users if their collection of code does/doesn’t work with a specific version of python.

Thanks for the comments everyone.

Just a clarification: I’m not asking whether we should dissuade users from using Python 3, I’m trying to explain that (on Ubuntu/Debian, probably the two most used OS, also because of the availability of binary pkgs) using anything but the system supplied Python environment is currently not a straightforward process.

This is more about package/module search paths than anything else, but it would appear that new users really struggle to understand what is going on. Somehow Anaconda is one of the ‘alternative’ interpreters that seems to come up the most on ROS Answers questions.

My recommendation is thus to draw their attention (‘warn’ may be too strong a word) to this, so they can avoid spending a day trying to figure out why catkin_make and their simple rospy scripts are failing.

1 Like

Just a few words to say that I appreciate and agree with the previous replies, ROS2 is python3, and ROS1 will have to move eventually to python3.

I also think we should warn that the only supported interpreter currently is CPython2.7 for ROS1.

However I think there is another reason for users and newcomers confusion coming to ROS, with python in other environment. One that hasnt been mentionned and needs to be addressed in ROS2 as well :

In python you don’t “make” anything, there is no build process, it is completely obsolete and hidden from the developer. Therefore newcomers have no idea and probably do not care about all these low level details, including dependencies and the like.

Python comes with its own set of problems and too few people have the resources and skills to manage both System and (portable) Python runtime environments.

If ROS is to be multi lingual it also has to adopt the culture and paradigm of each programming language community, somehow…

That could also be a warning : ROS1 is primarily a C oriented framework, make sure you are familiar with C development and your system libraries. If not, here(put awesome tutorial link here) is a quick tutorial.

At least until everything becomes doable using standard python tools only, with a python workflow : pip install thing; python thing run.

And if you re interested about that last part let me know. I already worked on ways to do that, but I m currently looking for resources to be able to maintain what is working at and keep moving forward, so any help is welcome.

I agree with you there are quite some conceptual differences, and the workflows of Python and other languages cannot be considered equal, but it’s not about having to run make, or having to use a build process.

After following the ROS (Ubuntu/Debian) installation tutorial, opening a text editor and writing your first rospy-based script, someone with an Anaconda or a (system managed/provided) Python 3 installation will always run into an ImportError: No module named rospy error.

That seems to already confuse new users enough that I was wondering whether we should document it.


I’m all for documenting and only recommending the use of a “system” Python 2 version. Using Python 3 and/or third party packing of Python (like Anaconda) should be considered exotic and will require additional steps, which the community can provide as there is demand for it.

As the Python 3 story improves for ROS 1 we can just link to the documentation about how to use it.

In any case, I’m all for raising the visibility of the issue in the installation documentation and the tutorials.

Is anyone interested in volunteering to lead the effort? I’m happy to review changes to the documentation and/or facilitate in any way that I can (giving access, reviewing changes, etc…), but realistically if I offer to do it we may all be waiting a long time for me to get around to it. :slight_smile:

Also we should wait to hear form some others on the core ROS team.

I don’t have much to add on top of what @wjwwood says.

A small note on the installation page(s) wouldn’t hurt as long as it is discrete enough to not confuse beginners who don’t know about the alternative python interpreters.

There is a level that setting up an alternative python interpreter is a moderately advanced topic and if you’re choosing to do that you will need to know and understand what you’re doing, and it will inherently take more steps.

We do want to make sure to be clear, I think that some well worded questions on with good answers might be the best approach. The question could aggregate all the right keywords and then provide a full complete answer that then can be referenced from lots of places might be the best approach. Maybe even using different answer to provide different approaches. And if we also go around and cross link to it from many of the other related questions then most people will find it quickly.

In general I agree with this sentiment, but Anaconda is different. It’s easy to install and a lot of people install it because they’re told it’s “Python, but better” or because it sounds like a neat idea or even just for kicks, without having a clue what it’s doing to their system. It’s got to the point where I have at least one person using Anaconda in every tutorial I run, and they almost never understand why it is making rospy usage fail. Having not used it myself the first couple of times this happened took me a while to fix, but now it’s got to the point where when someone is having trouble importing rospy the first thing I do is open up their .bashrc file and look for references to Anaconda. I don’t ask them first anymore, either, because a couple of people didn’t even remember installing it.

Having a good question and answer on is a good idea, but I think there is benefit in putting a very brief note with a link to it on the rospy tutorial page or somewhere like that.