On Mon, Oct 10, 2011 at 2:40 PM, Ken Conley
<kwc@willowgarage.com> wrote:
Thanks to all who provided comments on the rospkg API. Now that the comment deadline has passed, I have added a summary to the review page of proposed/adopted changes:
http://www.ros.org/wiki/rospkg/Reviews/2011-09%20rospkg#Meeting_agenda
I don't think it will be necessary to hold a formal meeting given that the changes are fairly simple.
Most of the changes are minor or additions of missing APIs. The main, breaking change being proposed is:
rospkg.RosPack(ros_root='foo', ros_package_path='path1:path2')
to
rospkg.RosPack(path=['foo', 'path1:path2'])
Sorry for the bad cut-and-paste, this should be:
rospkg.RosPack(path=['foo', 'path1', 'path2'])
As well a similar changes to remove explicit knowledge of ROS_ROOT and ROS_PACKAGE_PATH from the RosPack/RosStack APIs. The motivation for this change is forwards compatibility and versatility (see below).
This change was proposed by Tully and I'm inclined to accept it barring any objections (which you may not in the normal "+1", "-1" style).
- Ken
Forwards compatibility:
ROS_ROOT, as opposed to just a generic ROS_PACKAGE_PATH, is mainly necessary for constructing a system PATH; future changes will make this no longer necessary, and thus make ROS_ROOT vestigial.
Versatility:
By accepting a generic 'path' argument, the RosPack class is decoupled from any particular idea of environment variables, etc... It just knows there is an ordered set of paths it operates on.
On Thu, Oct 6, 2011 at 11:27 AM, Ken Conley
<kwc@willowgarage.com> wrote:
Good suggestion. As this is the behavior of rospack, I changed rospkg
to match it by default. You can get the raw export by adding a
"convert=False" arg to the get_export() call instead.
A minor cosmetic issue is the printing of "READ_CACHE manifest.xml" in
rospkg/rospack.py:188.
I guest this output will be removed in the next release?
Yes, this has already been removed. I pushed 0.2.3 with the fix as
well as updated get_export() API.
It would be useful if the version number of rospkg could be determined.
This is not yet possible, right?
So could you also add a function which returns the version number of rospkg?
Great idea. Added in the next version:
$ python -c "import rospkg; print rospkg.__version__"
0.2.4