A new version of REP 114 is now available:
http://www.ros.org/reps/rep-0114.html
The sphinx API docs are also updated. To test the standalone
infrastructure, the docs are hosted on readthedocs.org:
http://readthedocs.org/docs/rospkg/en/latest/
The main changes are:
1. rosdistro APIs are now part of rospkg. I refactored rosdistro to
no longer depend on vcstools and cleaned up the API. This change will
enable more tools to depend on the standalone toolchain.
2. Changed OS version semantics in os_detect. A version is now a
version number; there is a separate accessor for OS codenames (e.g.
'hardy').
SVN diff is attached for comparison.
- Ken
On Mon, Aug 22, 2011 at 7:31 PM, Ken Conley <
kwc@willowgarage.com> wrote:
> On Mon, Aug 22, 2011 at 6:28 PM, Brian Gerkey <gerkey@willowgarage.com> wrote:
>> +1.
>>
>> What should we do with rospack? Seems like the same reasoning that
>> leads to splitting out rospkg would suggest separate packaging of
>> rospack (and rosstack).
>
> Yes, that is the plan. They will be optional dependencies of rospkg,
> and eventually all would be combined into a 'ros' bootstrap debian
> that was distribution-independent. It's also possible that some of
> the other binaries in ros/bin could go in this -- in particular, the
> python scripts that follow the 'import foo; foo.main()' sort of
> pattern.
>
> My only concern with rospack is librospack, which could use some
> improvements before it goes bigger.
>
> - Ken
>
>> brian.
>>
>> On Thu, Aug 18, 2011 at 2:48 PM, Ken Conley <kwc@willowgarage.com> wrote:
>>> I have posted a draft REP 114: rospkg standalone library. It is
>>> intended as a rewrite of the roslib Python library, this time with a
>>> publicly supported API. It is also standalone, i.e. it can be
>>> installed separately from ROS. The intent for this library is to
>>> support develop of ROS tools that are decoupled from a particular ROS
>>> distribution release as well as become the basis for future ROS tool
>>> bootstrapping.
>>>
>>> http://www.ros.org/reps/rep-0114.html
>>>
>>> At its heart it can be thought of as a Python rospack/rosstack, though
>>> it goes a little beyond that. The first targeted use of the rospkg
>>> library is a rewrite of the rosdep library to also be standalone.
>>>
>>> The REP notes current open questions/issues for discussion.
>>>
>>> I have also written documentation here:
>>>
>>> http://www.ros.org/doc/api/rospkg/html/sphinx/html/
>>>
>>> It includes the start of a developer's guide for those that wish to
>>> also develop/maintain this library. As this library may become the
>>> bootstrap library for ROS in the future, I encourage those that are
>>> interested to get involved.
>>>
>>> cheers,
>>> Ken
>>> _______________________________________________
>>> ros-users mailing list
>>> ros-users@code.ros.org
>>> https://code.ros.org/mailman/listinfo/ros-users
>>>
>>
>>
>>
>> --
>> http://brian.gerkey.org
>> _______________________________________________
>> ros-users mailing list
>> ros-users@code.ros.org
>> https://code.ros.org/mailman/listinfo/ros-users
>>
>
Index: rep-0114.txt
===================================================================
--- rep-0114.txt (revision 132)
+++ rep-0114.txt (working copy)
@@ -7,7 +7,7 @@
Type: Informational
Content-Type: text/x-rst
Created: 18-Aug-2011
-Post-History: 18-Aug-2011
+Post-History: 18-Aug-2011, 06-Sep-2011
Abstract
========
@@ -101,6 +101,9 @@
- ``roslib.environment``
+The ``rospkg`` Python module also supercedes the ``rosdistro`` module.
+
+
environment APIs
----------------
@@ -172,16 +175,23 @@
There is a separate ``rosdistro`` ROS package that supports parsing of
ROS ``.rosdistro`` files. These files describe a ROS distribution,
-which is a collection of ROS stacks at a particular version. As a ROS
-distribution is conceptually part of the ROS package ecosystem and as
-many support tools require this library as well, we may wish to
-consider putting it into the ``rospkg`` module in the future.
-However, this would require putting the ``vcstools`` module in
-``rospkg`` as well. The ``vcstools`` module is currently undergoing
-major development, so it is not ideal for putting in ``rospkg`` right
-now.
+which is a collection of ROS stacks at a particular version.
+The ``rosdistro`` ROS package has been included for porting to rospkg
+as a ROS distribution is conceptually part of the ROS package ecosystem.
+The rosdistro module is also heavily used in the toolchain that rospkg
+is intended to support.
+Recent changes to the ``rosdistro``` package have made it easier to port. The
+dependency on the ``vcstools`` package have been removed so the
+distribution-related code can now be packaged standalone.
+
+As distributions are not a primary concept like packages and stacks,
+the distribution-related APIs are being kept in the ``rospkg.distro``
+submodule. These APIs are also not as stable as the package and stack
+APIs.
+
+
Compatibility
=============
@@ -208,7 +218,28 @@
It also removes the ability to marshal instances to XML, which is not
vital functionality and is bug-prone.
+os_detect
+---------
+The ``rospkg.os_detect`` module differs from ``roslib.os_detect`` in the
+definition of an OS "version". In the ``roslib`` API, version
+can be a codename or a pure version number, depending on the specific OS.
+This is largely an artifact of the library originally being a rosdep support
+library.
+
+In the interest of consistency and supporting a longer-term API, the
+definitionis have been migrated to be more like ``lsb_release``-style
+[9]_, which provides the version number and codename separately.
+
+
+rospkg.distro
+-------------
+
+The new ``rospkg.distro`` format streamlines the distribution API by
+removing backwards-compatibility support for older rosdistro formats.
+It also simplifies up access to stack and release information.
+
+
Open issues
===========
@@ -227,16 +258,6 @@
supported in the long-term under the backwards-compatibility
requirement of rospkg.
-rospkg.os_detect
-----------------
-
-The definition of an OS name and version are heavily geared towards
-the rosdep definition. Sometimes version is equivalent to 'codename';
-in other cases it is a version number. In the interest of supporting
-a longer-term API, it may be worthwhile to migrate to an
-``lsb_release``-style API [9]_ that provides the version number and
-codename separately.
-
Manifest
--------
(text/plain)