Along those lines, what if the setup.bash includes a ROS_WORKSPACE environment variable? It would enable: * no longer have to specify path in rosworkspace commands * integrate with roscd * do things like 'alias setup=source $ROS_WORKSPACE/setup.bash' Alternate workflow: $ source /opt/ros/unstable/setup.bash $ rosworkspace init /tmp/work # sets ROS_WORKSPACE=/tmp/work $ source /tmp/work/setup.bash # add multiple stacks to workspace $ rosworkspace add navigation laser_pipeline # requires update to rosbash $ roscd workspace # get released version of camera_drivers instead of devel $ rosworkspace add camera_drivers --release # add to a different workspace $ rosworkspace add navigation --path=/tmp/other # enable the other workspace $ source /tmp/other/setup.bash $ rosworkspace delete navigation On Tue, Jul 12, 2011 at 9:22 PM, William Woodall wrote: > 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. > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > William Woodall > Graduate Software Engineering > Auburn University > w@auburn.edu > wjwwood@gmail.com > williamjwoodall.com > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > On Tue, Jul 12, 2011 at 11:06 PM, Brian Gerkey > wrote: >> >> hi, >> >> Exploiting Ken's work on a version-specific roslocate index [1], I put >> together a new tool, tentatively called `rosworkspace`.  The idea is >> that it will help you manage your ROS workspace (aka overlay), which >> can get kind of complicated when you're developing several stacks at >> once, or frequently switching between development contexts. >> >> rosworkspace can pull any released stack, as well as stacks that >> depend on it, from source, using either the development branch or the >> latest release tag, conditioned on your ROS distro.  It's really just >> a front-end for rosinstall, with some calls to roslocate and rosstack. >> >> Example usage: >> ------ >> # Start with the system installation >> $ source /opt/ros/unstable/setup.bash >> # Create a workspace, bootstrapping from ROS_ROOT >> # and ROS_PACKAGE_PATH >> $ rosworkspace /tmp/work init >> # Now I have an empty workspace in /tmp/work >> $ source /tmp/work/setup.bash >> # I want to hack on navigation >> $ rosworkspace /tmp/work add navigation >> # Now my workspace contains the unstable development branch for >> # navigation, as well as all stacks that depend on navigation. >> $ source /tmp/work/setup.bash >> $ rospack find amcl >> /tmp/work/navigation/amcl >> $ rosstack find pr2_plugs >> /tmp/work/pr2_plugs >> # Now I'm done hacking on navigation, and I want to revert to the >> # system install >> $ rosworkspace /tmp/work delete navigation >> $ source /tmp/work/setup.bash >> $ rospack find amcl >> /opt/ros/unstable/stacks/navigation/amcl >> $ rosstack find pr2_plugs >> /opt/ros/unstable/stacks/pr2_plugs >> ------ >> >> To give it a try, grab the latest rosinstall and adjust your PATH: >> $ svn co https://code.ros.org/svn/ros/stacks/ros_release/trunk/rosinstall >> $ export PATH=`pwd`/rosinstall/scripts:$PATH >> >> Comments most welcome.  I'm interested to hear whether such a tool >> would be useful, and if so, what command-line syntax and defaults >> would best support common workflows. >> >>        brian. >> >> [1] https://code.ros.org/lurker/message/20110711.160222.666ecfe4.en.html >> _______________________________________________ >> ros-users mailing list >> ros-users@code.ros.org >> https://code.ros.org/mailman/listinfo/ros-users > > > _______________________________________________ > ros-users mailing list > ros-users@code.ros.org > https://code.ros.org/mailman/listinfo/ros-users > >