[ros-users] RFC: rosworkspace

Ken Conley kwc at willowgarage.com
Wed Jul 13 09:20:05 UTC 2011 

To throw another tool onto the pile for comment as its related:

rosco [file]: checks out a rosinstall fragment and nothing more

Example:

# checkout all entries in foo.rosinstall to this directory
rosco foo.rosinstall

# lookup snippet for eigen and check it out
roslocate info eigen --distro=unstable | rosco


This is for a different use case, basically "gimme code now." It's not
particularly good if you're trying to do development, but good if you
just need to browse through a code tree or do a quick tweak.  I built
this tonight because I got tired of typing "svn co `roslocate uri foo`
foo".

You can fetch from here:

 * hg:  https://kforge.ros.org/kwc/rosco
 * wget: https://kforge.ros.org/kwc/rosco/raw-file/437f02319ff3/rosco


On Wed, Jul 13, 2011 at 1:50 AM, Geoffrey Biggs
<geoffrey.biggs at aist.go.jp> wrote:
> It needs a shorter command. rosws?
>
> Geoff
>
> On 13/07/11 16:37, Brian Gerkey wrote:
>> On Tue, Jul 12, 2011 at 9:58 PM, Ken Conley<kwc at willowgarage.com>  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
>> <work, work, work>
>>
>> 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<wjwwood at 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 at auburn.edu
>>>> wjwwood at gmail.com
>>>> williamjwoodall.com
>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>>
>>>>
>>>> On Tue, Jul 12, 2011 at 11:06 PM, Brian Gerkey<gerkey at 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 at code.ros.org
>>>>> https://code.ros.org/mailman/listinfo/ros-users
>>>>
>>>>
>>>> _______________________________________________
>>>> ros-users mailing list
>>>> ros-users at code.ros.org
>>>> https://code.ros.org/mailman/listinfo/ros-users
>>>>
>>>>
>>> _______________________________________________
>>> ros-users mailing list
>>> ros-users at code.ros.org
>>> https://code.ros.org/mailman/listinfo/ros-users
>>>
>> _______________________________________________
>> ros-users mailing list
>> ros-users at code.ros.org
>> https://code.ros.org/mailman/listinfo/ros-users
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>

More information about the ros-users mailing list