[ros-users] SVN Trunk: rospkg dependency and rostopic bug

[Dantam, Neil T]

Hi,

* rospkg/genpy/genmsg *

It looks like a dependency on rospkg/genpy/genmsg has been introduced
into roscore in the SVN trunk.

The following files do an import rospkg:

bin/rosservice
core/roslib/src/roslib/gentools.py
core/roslib/src/roslib/msgs.py
core/roslib/src/roslib/packages.py
core/roslib/src/roslib/rospack.py
core/roslib/src/roslib/stacks.py
test/test_roslib/test/test_roslib_stacks.py
tools/rosclean/src/rosclean.py
tools/roscreate/src/roscreate/roscreatestack.py
tools/rosdep/src/rosdep/core.py
tools/rosdep/src/rosdep/main.py
tools/rosmake/src/rosmake/engine.py
tools/rosunit/scripts/clean_junit_xml.py
tools/rosunit/scripts/test_results_dir.py
tools/rosunit/src/rosunit/baretest.py
tools/rosunit/src/rosunit/core.py
tools/rosunit/src/rosunit/junitxml.py

The following files do an import genpy:

core/roslib/src/roslib/message.py

Pulling in genpy via easy_install also pulls down genmsg as a
dependency.  Troy Straszheim suggested that perhaps this was not
desirable.

Maybe someone familiar with these changes can comment on what the
appropriate behavior should be?

* rostopic *

Using https://code.ros.org/svn/ros/stacks/ros/trunk@15300,
rostopic fails with the following stack trace:

Traceback (most recent call last):
  File "/home/mechsoph/ros/ros/bin/rostopic", line 38, in <module>
    d = roslib.stacks.get_stack_dir('ros_comm')
  File "/home/mechsoph/ros/ros/core/roslib/src/roslib/stacks.py", line 124, in get_stack_dir
    _update_stack_cache(env=env) #update cache
  File "/home/mechsoph/ros/ros/core/roslib/src/roslib/stacks.py", line 156, in _update_stack_cache
    pkg_dirs = rospkg.environment.compute_package_paths(ros_root, ros_package_path)
AttributeError: 'module' object has no attribute 'compute_package_paths'

In rospkg 0.9.0 (the version easy_install gave me), the function looks
like rospkg.environment._compute_package_paths (note the underscore),
and if I add that underscore in stacks.py:156, then rostopic runs (not
that that's the most appropriate fix here).

--
Neil Dantam
http://www.cc.gatech.edu/~ndantam3