On Tue, Jul 12, 2011 at 9:58 PM, Ken Conley wrote: > Along those lines, what if the setup.bash includes a ROS_WORKSPACE > environment variable? I like it. Implemented, r14302. I just used the new version to do a little work on stage, like so: source /opt/ros/unstable/setup.bash rosworkspace init unstable-stage source unstable-stage/setup.bash rosworkspace add stage source unstable-stage/setup.bash roscd stage Straightforward, though still a lot of sourcing. The `setup` alias is probably worth it. brian. p.s. The ROS_WORKSPACE name sounded familiar to me, and, sure enough, Morgan gets the credit for prototyping a similar tool 2 years ago: https://code.ros.org/trac/ros/changeset/6047 :) > > 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 >> >> > _______________________________________________ > ros-users mailing list > ros-users@code.ros.org > https://code.ros.org/mailman/listinfo/ros-users >