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

Thibault Kruse kruset at in.tum.de
Fri Oct 28 17:22:14 UTC 2011


Hi Tully,

I believe you try to revive the rosws discussion started by Brian
"[ros-users] RFC: rosworkspace", not the REP 110 discussion
that went under the subject to which you replied.

For REP 110 (changing the rosinstall syntax and also the command
name) I wait for your opinion as rosinstall maintainer on when and
how this would be good to do.

I remember you once wanted to keep rosinstall and configuration
management separated, so if rosinstall were renamed rosws as per
REP 110, then configuration management would need a different
command.

As to storing .rosinstall and .rosws files, I would like to see them
stored in a folder much like a .git or .hg folder. This also allows to
keep these folders under version control and thus have a simple
configuration management. It is possible now with symbolic links,
but a bit clumsy.

As for actual configuration management, I think it would be good
to think in broader terms than "released" and "develop", and beyond
the scope of willow garage stacks.
Teams in the wild working on their own stacks based on their own
repositories could benefit from a broader solution. Such a solution
might define versioned configurations with release numbers.
So there could be a remote repository which contains nothing but
a rosinstall file, with several tags and branches defining release cycles.

Based on this idea the states of a local repository would not be
undeclared, development, released
but
undeclared or declared with baseline xyz (tag or branch of a configuration).

I have not thought this through all the way, such as considering 
"subscribing"
to several baselines, such as mixing the future willow garage stack 
baselines
with baselines for stacks from the own and other teams.

And just as rosinstall mixes multivcs with ROS concerns, you seem
now to be mixing general configuration management concerns with
ROS concerns. I like the idea of splitting up rosinstall into a 
ROS-agnostic
multivcs library and a tiny layer on top of it to manage generation of
ROS setup files.
And in the same way I would recommend to think about configuration
management with multiple heterogenous sources independently of
ROS from the start.

cheers,
   Thibault



On 10/27/2011 10:11 PM, Tully Foote wrote:
> 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
>>
>
>




More information about the ros-users mailing list