This seems really useful, I find my self setting up work spaces often and/or doing bad things like adding all my packages to one folder in my ros_packge_path (something like ~/devel/ros/stacks).  I think an addition to the example work flow might be to set a current (persistent) work space so that future commands will assume that you are working in /tmp/work unless otherwise specified.  This would also allow for auto-resourcing of the setup.bash in that work space.<div>

<br></div><div>--</div><div><br clear="all">~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>William Woodall<br>Graduate Software Engineering<br>Auburn University<br><a href="mailto:w@auburn.edu" target="_blank">w@auburn.edu</a><br><a href="mailto:wjwwood@gmail.com" target="_blank">wjwwood@gmail.com</a><div>

<a href="http://williamjwoodall.com" target="_blank">williamjwoodall.com</a><br>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~</div><br>
<br><br><div class="gmail_quote">On Tue, Jul 12, 2011 at 11:06 PM, Brian Gerkey <span dir="ltr">&lt;<a href="mailto:gerkey@willowgarage.com">gerkey@willowgarage.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

hi,<br>
<br>
Exploiting Ken&#39;s work on a version-specific roslocate index [1], I put<br>
together a new tool, tentatively called `rosworkspace`.  The idea is<br>
that it will help you manage your ROS workspace (aka overlay), which<br>
can get kind of complicated when you&#39;re developing several stacks at<br>
once, or frequently switching between development contexts.<br>
<br>
rosworkspace can pull any released stack, as well as stacks that<br>
depend on it, from source, using either the development branch or the<br>
latest release tag, conditioned on your ROS distro.  It&#39;s really just<br>
a front-end for rosinstall, with some calls to roslocate and rosstack.<br>
<br>
Example usage:<br>
------<br>
# Start with the system installation<br>
$ source /opt/ros/unstable/setup.bash<br>
# Create a workspace, bootstrapping from ROS_ROOT<br>
# and ROS_PACKAGE_PATH<br>
$ rosworkspace /tmp/work init<br>
# Now I have an empty workspace in /tmp/work<br>
$ source /tmp/work/setup.bash<br>
# I want to hack on navigation<br>
$ rosworkspace /tmp/work add navigation<br>
# Now my workspace contains the unstable development branch for<br>
# navigation, as well as all stacks that depend on navigation.<br>
$ source /tmp/work/setup.bash<br>
$ rospack find amcl<br>
/tmp/work/navigation/amcl<br>
$ rosstack find pr2_plugs<br>
/tmp/work/pr2_plugs<br>
# Now I&#39;m done hacking on navigation, and I want to revert to the<br>
# system install<br>
$ rosworkspace /tmp/work delete navigation<br>
$ source /tmp/work/setup.bash<br>
$ rospack find amcl<br>
/opt/ros/unstable/stacks/navigation/amcl<br>
$ rosstack find pr2_plugs<br>
/opt/ros/unstable/stacks/pr2_plugs<br>
------<br>
<br>
To give it a try, grab the latest rosinstall and adjust your PATH:<br>
$ svn co <a href="https://code.ros.org/svn/ros/stacks/ros_release/trunk/rosinstall" target="_blank">https://code.ros.org/svn/ros/stacks/ros_release/trunk/rosinstall</a><br>
$ export PATH=`pwd`/rosinstall/scripts:$PATH<br>
<br>
Comments most welcome.  I&#39;m interested to hear whether such a tool<br>
would be useful, and if so, what command-line syntax and defaults<br>
would best support common workflows.<br>
<br>
        brian.<br>
<br>
[1] <a href="https://code.ros.org/lurker/message/20110711.160222.666ecfe4.en.html" target="_blank">https://code.ros.org/lurker/message/20110711.160222.666ecfe4.en.html</a><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>
</blockquote></div><br></div>