[ros-users] rospy and python 3.0

[Ken Conley]

Great!

Comments below.

On Tue, Nov 30, 2010 at 9:42 AM, Severin Lemaignan
<severin.lemaignan at laas.fr> wrote:
> I say 'almost' because the test_rospack still fails with this error:
>
>
> [test_rospack.test_utest/test_ran][FAILURE]-------------------------------------
>  Unable to find test results for TEST-test_utest.xml, test did not run.
> Expected results in .ros/test_results/test_rospack/TEST-test_utest.xml
>
> which does not seem to be related to the port to Python 3 (but I may be
> wrong: it may be some side-effect...)

That is a python-based unit test, so perhaps that's the issue.

> Porting what we did on the rospy package to the SVN trunk is still pending.
>
> Be aware that the new version requires Python >= 2.6 (but I think it was
> already assumed from the syntax I saw in the original files).

The syntax is Python 2.5 (e.g. "from __future__ import
with_statement"). Diamondback will be Python 2.5, we have not yet
determined what E-Turtle will be, though I have confidence that it
will be 2.6.

http://www.ros.org/reps/rep-0003.html

> I had some issues with regexp in junitxml.py:_read_file_safe_xml() so I
> commented it out for now.
>
> I've re-organized the GIT repos by stacks, and the changes to the ros stack
> are here:
> http://code.in.tum.de/indefero/index.php//p/rospy3-stacks-ros/source/tree/master/
>
> Find attached the (huge) patch against SVN trunk.
>
> Comments most welcome!

It will also be best to deal with the patch tool-by-tool.  That way me
and Tully can deal with the patches separately.  Also, given that ROS
is now split into ros and ros_comm, I think first we can target the
'ros' stack, and then target the ros_comm stack afterwards.

However, right now, we have not yet branched for e-turtle. We're still
dealing with the effects of splitting ros and ros_comm, and it would
not be a good idea for us to branch the codebase until that is
settled.  However, I do expect that the base 'ros' stack would be
ready to accept patches soon.

Can you go ahead and create a ticket with your patch -- given that the
time period for merging this will likely be a least several weeks
away, it will make sure that this gets targeted properly.  Also, if
the patch is split tool-wise, it is much more likely that we will be
able to tackle it sooner.

thanks,
Ken