[ros-users] rosinstall file syntax

[Thibault Kruse]

Hi all,

I'd like opinions and ideas on the rosinstall yaml syntax. Currently the
syntax is like in these examples:
- other: {local-name: /opt/ros/fuerte}
- svn: {local-name: common_msgs, uri:
'https://code.ros.org/svn/ros-pkg/stacks/common_msgs/tags/common_msgs-1.4.0',
version: ''}
- setup-file: {local-name: /opt/ros/fuerte/setup.sh}

This syntax design has major flaws, it mixes content with structure (git
is a content information), it allows entries which are semantically not
supported (e.g.: - {svn :{...}, hg: {...}}), and it is not very extendable
(keywords uri and version are gone).

I have been thinking about implementing an alternative syntax that does
not overlap with the existing one, could be used in parallel, and could
replace the old syntax in the long run.

My draft looks like this in comparison:
- path: /opt/ros/fuerte
- path: common_msgs
  scm: {type: git, uri:
'https://code.ros.org/svn/ros-pkg/stacks/common_msgs/tags/common_msgs-1.4.0',
version: ''}
- path: common_msgs
  tags: {setup-file:}

Semantically this structure restricts us to one scm per path (based on
rosinstall logic of unique paths), and single scm uri per path (as opposed
to distributed models). But I do not see the effort to be flexible for any
of these aspects worth the benefit.

Having 2 syntaxes also means ambiguous information across wikis and
tutorials, users could become confused about which is the "right" syntax.

Another idea Ken mentioned to me was to extend the syntax to contain more
information about the environment the rosinstall tool should generate,
such as how to set variables like ROS_ROOT, ROS_PACKAGE_PATH,
ROS_MASTER_URI, PYTHONPATH, LD_LIBRARY_PATH, etc.

When I started adding those pieces to the syntax I felt like I was
creating a scripting language, and so I felt like I was doing something
wrong. As an alternative solution to the problem, I could think of
introducing something like .rosinstallrc files.
Those, dropped in any entry of the ROS_PACKAGE_PATH (or also in
ROS_WORKSPACE), could be sourced by the setup.sh. That way, scripting
problems are solved by a scripting language, and projects are free to use
the full scripting syntax of shell.
Also this means a project env can be set up in the absence of rosinstall
of a rosinstall workspace, by manually sourcing that file. The risk of
that approach is that these files should not ever be used as a replacement
for a standard buildtool like cmake, but some people could be tempted to
rely on the files for that.

Do you have opinions and/or ideas regarding the syntax change or the
environment scripts?

cheers,
  Thibault