[ros-users] rosinstall file syntax

[Ken Conley]

On Thu, Mar 1, 2012 at 8:26 PM, Thibault Kruse <kruset at in.tum.de> wrote:
> 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.

To clarify: the main idea was that the syntax enable exporting
*path*-based environment variable settings (i.e. indicate that a path
override or accumulate to an environment variable).  Thus,
ROS_MASTER_URI is not part of the proposal.

> 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
>
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users