I've tried it out and it's very convenient.  <br><br>I found a few usability issues.  The visibility of the ROS_WORKSPACE variable is low.  I created  a workspace in one directory, then went into another.  I called init and then add and it added it to the first, which was very non-intuitive.  I think this could be fixed with putting some printouts in the <a href="http://setup.sh/bash">setup.sh/bash</a> scripts which state what they are doing.  Also a nice "Now source your setup.(ba)sh" instruction before rosws init quits would help.  <br>

<br>The other issues I had was that I added navigation and then pr2_navigation and when I removed navigation pr2_navigation went away too.  This is indicitative of not actually knowing what the users wants, just the state of the system.  Also related to this is that it implicitly relies on having the stacks preinstalled in the binary tree.  <br>

<br>In thinking it through there are three inputs the user needs to provide to define their workspace.  The list of stacks they want from development branches(currently done by adding), the list of stacks they want from released sources(using --released option, useful for providing patches), and the total list of capabilities which they want available(currently implied by the binary installation).  From these three lists the workspace can be constructed.  <br>

<br>The other two elephants in the room are support for custom rosinstall snippets and for binary package installation.  Right now the system relies on the binaries already being present and the source system just overlaying on top.  This could be extended to support anything in the distro file relatively easily, and install the binary packages underneath if they are available.  <br>

<br>As for custom rosinstall snippets I don't think need to be handled explicitly but we need to make sure not to clobber the custom rosinstall snippets when "deleting" elements.  <br><br>Thoughts?<br><br>Tully<br>

<br><div class="gmail_quote">On Tue, Jul 19, 2011 at 1:58 PM, Brian Gerkey <span dir="ltr"><<a href="mailto:gerkey@willowgarage.com">gerkey@willowgarage.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

Ok, I changed the name to `rosws`, queued it up for inclusion in the<br>
next `rosinstall` release (0.5.17), and documented it here:<br>
<br>
<a href="http://www.ros.org/wiki/rosws" target="_blank">http://www.ros.org/wiki/rosws</a><br>
<br>
Further feedback is most welcome.<br>
<font color="#888888"><br>
        brian.<br>
</font><div><div></div><div class="h5"><br>
On Wed, Jul 13, 2011 at 2:17 AM, Brian Gerkey <<a href="mailto:gerkey@willowgarage.com">gerkey@willowgarage.com</a>> wrote:<br>
> On Wed, Jul 13, 2011 at 1:50 AM, Geoffrey Biggs<br>
> <<a href="mailto:geoffrey.biggs@aist.go.jp">geoffrey.biggs@aist.go.jp</a>> wrote:<br>
>> It needs a shorter command. rosws?<br>
><br>
> hi Geoff,<br>
><br>
> I like rosws, too.  My only concern is that there's already a thing<br>
> called rosws, which is ROS over websockets.  So I was worried about<br>
> the name collision.  But it's likely worth it to shorten the command.<br>
><br>
>        brian.<br>
><br>
_______________________________________________<br>
ros-users mailing list<br>
<a href="mailto:ros-users@code.ros.org">ros-users@code.ros.org</a><br>
<a href="https://code.ros.org/mailman/listinfo/ros-users" target="_blank">https://code.ros.org/mailman/listinfo/ros-users</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Tully Foote<br>Systems Engineer<br>Willow Garage, Inc.<br><a href="mailto:tfoote@willowgarage.com">tfoote@willowgarage.com</a><br>(650) 475-2827<br>