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 <
wjwwood@gmail.com> 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 <gerkey@willowgarage.com>
> 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
>
>
(text/plain)