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 though 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.
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.
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 http://github.com/pyros-dev 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.
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 answers.ros.org 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 answers.ros.org 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.
Related but not the same though, why pip is kind of optional in rosdep key list, and the things to note for when depending on pip packages from your pkg might be worth being noted too. For the former thereâs been answers on answers.ros.org. For the latter, thereâs been discussions/posts here and there. A good one by @tfoote might be this rosdistro!18840.
I thought itâs close enough to this thread but I can open a separate one if desired (UPDATE: I didnât know this thread was 2 years oldâŚHad I known that I wouldâve opened a new one, but oh well).
There should be banner request to think carefully before re-opening threads that are over 30 days old. Is that not the case? I would generally prefer we not revisit threads where the underlying information may be substantially out of date.
Thereâs not really anything which is outdated here: in both Kinetic and Melodic the issues I describe in the OP and the others in the follow-up posts are still present. We still get questions about it on ROS Answers.
And actually: if users are using interpreters which are really isolated / using isolated runtime environments, theyâll also run into the described problem with Noetic.
Whether @130sâ question is off-topic for this thread would be something else.
As someone who had to wrestle with ROS Ingigo and Kinetic to run with python3 (to incorporate latest AI frameworks which are ALL on python3) I think that there must be an official page that describes how people should approach this.
Yes, the official python used in ROS1 is still system python2.7. But there are ways to run all ROS1 things on python3. Yes, some packages may not work. But it should be up to people to deal with that. Right now people are either reinventing this wheel every time or running system which is a messy mix of python2 and python3. There should be centrally described best practice how to do that
Gulp. I guess this will put a hold to my son learning ROS and python this year. Python2.7 will NOT be maintained past 2020 âŚ
oh wait its already 2020 . (see : https://pythonclock.org/ or even https://www.python.org/doc/sunset-python-2/) so with that being said is there a version of ROS that totally supports python3?
