[ros-users] [Ros-developers] Fwd: rosinstall refactoring

[Tully Foote]

Hi all,

As this conversation has languished a bit I wanted to revive it.  I
spent some time in front of a whiteboard and talked to people as they
went past as I was sketching how this might work.

Thanks to Thibault's patches if you'd like to try out rosinstall
commands --status and --diff the latest version of rosinstall has them
implemented for testing but not documented until this process is done.

In my brainstorming, I started with the premise that this would be a
tool which would do configuration management and would leverage
rosinstall underneath.  And to be able to help you the most at
initialization it will need to know what distro it is working against.
Similarly as we've talked about before there seems to be a consensus
that scm type syntax is preferred, so like svn, hg, and git it will
look at the current tree and traverse upwards so as not to need to
take a path in every call.  A global --path option can be used to
allow execution of any command from an arbitrary CURDIR

Also there are three common states for a package which the user cares
about.  The user will want the development version of a package, the
released version of a package, or they don't care, which I'll call
undeclared.  Starting with the simplest, a development stack will
simply be checked out from the development branch for the distro.
Then all the dependencies of the union of development stacks and
declared "released" stacks is computed.  Any package dependent on the
development stack(s) is installed from source, while all other stacks
are installed from binary if possible.  Undeclared is the default
state, and the stack will be installed if another stack depends on it.

These states are mutually exclusive, and we could provide commands to
switch between them for each stack.  And for flexibility, we could
allow overriding the local-name and version.  local-name would default
to the stack name in the workspace.  And the version would default to
the value defined in the rosdistro file.

There are 6 transitions between the 3 states possible, after
considering different commands for each leg, a more declarative
statement of the end state will make things simpler.  Below are the 6
transitions and my proposed commands
undeclared => development  command develop
undeclared => released    command released
released => undeclared    command undeclare
released => development   command develop
development => undeclared   command undeclare
development => released     command released

For advanced users who have a very special configuration a .rosinstall
file will be supported, and appended to all calls to rosinstall.
(U16)

The configuration status can be stored in a .rosws file.
{{{
distro: electric
development:
 - geometry:
released: [rviz]
}}}

= Commands =

rosws init DISTRO=DEFAULT_DISTRO PATH='.'
 * Initialize the directory PATH as a ros workspace, with the
DEFAULT_DISTRO, electric as default.

rosws develop STACKNAME [--version branchname] [--local-name alt_local_path]
 * Add STACKNAME to the list of stacks to install the development branch

rosws undeclare STACKNAME
 * remove the stack from either development list or released list

rosws released STACKNAME
 * set the stack to be the released version

rosws snapshot
 * create a rosinstall file which is a snapshot of all the source
based installations, assumes binary installations are present as
required
 * --full an option to export a rosinstall with a full source based
installation for true snapshotting.
 * --tarball an option to generate a completely self standing tarball
of all the stacks source ready to build.
 * -O output_filename

rosws diff
 * output the diffs from each source checkout

rosws status
 * output the status of each source checkout

rosws info
 * display the current state of the configuration in a nice human
readable format



= Syncronization =
 rosws executes on every command.  Multiple arguments can be passed on
one line and execution will be deferred until the end state and
options except for global ones are left associative.

rosws init electric develop geometry --version not_optimized released
visualization

Would checkout geometry version not_optimized and everything up
through visualization from source at the end.


= Use case analysis =

Sample usage:
Stack developer who wants to develop stack geometry in ROS electric
and test up through rviz
cd /tmp/test
rosws init electric
rosws develop geometry
rosws released rviz
. setup.bash
DO SOMETHING IN GEOMETRY
rosmake rviz -t

Sample usage: Duplicate another workspace U1, U2
cd /tmp/test
rosws init --config /tmp/other_ws/.rosws

Follow above with below for U3
rosws develop geometry

Follow avove with belwo for U4
rosws released rviz

U5
rosws update

U6: changing the version of a stack
rosws develop geometry
OR
rosws released geometry
OR
rosws undeclare geometry

U7:
rosws released rviz

U8: NA not order dependent.

U9:
rosws purge

U10: NA

U11:
rosws snapshop -O config.filename

U12:
rosws init --config-file=filename

U13:
rosws develop ros

U14: duplicate U1

U15:
rosws develop geometry --local-name my/custom/path

U16:
Make changes to .rosinstall in the root directory

U17
rosws diff

U18
rowsw status


= My Comments =
I feel that the snapshot function is the least well defined.  I can
think of many different use cases with different requirements.  I'm a
little worried about trying to do to much and doing it inadaquately.
Most of the features could be covered by copying the .rosws and
.rosinstall together.

All the choices of names and verbiage should be reviewed.  In
particular the "released' and "undeclare" keywords seem like they
could be reforumlated to make more sense.

Thoughts?

Tully




On Wed, Aug 10, 2011 at 9:01 PM, Ken Conley <kwc at willowgarage.com> wrote:
> The new REP 110 document has been resynced to:
>
> http://www.ros.org/reps/rep-0110.html
>
>  - Ken
>
> On Wed, Aug 10, 2011 at 2:22 PM, Thibault Kruse <kruset at in.tum.de> wrote:
>> Sorry for me being slow on REP 110.
>>
>> I updated the REP document still on
>> http://code.in.tum.de/indefero/index.php//p/rosinstall2/source/tree/master/rosinstall-REP.txt
>>
>> For now I suggest in the REP to use rosws as name. I cut down the
>> diverse commands init, update, add, remove, ... to just install. Which
>> makes the REP look a bit silly, as I list 18 use cases most of which now
>> are served by "manually update your .rosinstall, then run 'rosws install .'"
>>
>> To reduce the wait time for the features I might, if Tully agrees,
>> provide status, diff, info as -- options in rosinstall as it is, then
>> the REP would really just change the syntax, not introduce features.
>>
>> regards,
>>   Thibault
>> _______________________________________________
>> 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
>



-- 
Tully Foote
Systems Engineer
Willow Garage, Inc.
tfoote at willowgarage.com
(650) 475-2827