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

[Thibault Kruse]

Thanks Tully for the feedback,

 > The other commands start to get into configuration management
 > and although they share a lot of the names of SCM commands
 > they actually are noteably different. init, add, remove, apply, 
update, check.

True for all but check. Though bzr check exists, but I'd also go with 
rosinstall wtf

I still think "check" may be useful, providing verbose information for 
all that is strange but not dangerous, like
- stacks mentioned in .rosinstall but missing
- stacks in ROS_PACKAGE_PATH after ROS_ROOT
- duplicate URIs
- different .rosinstall and setup.sh
I think all future rosinstall should give warnings on such occasions, 
and "check" would be the verbose information about the warnings.

 > And as Dave suggested adding status would be good.

I will implement the status command. "info" in its current state already 
shows a flag modified or not, but as a list of modified files, the 
outputs of the scm status commands will have to be post-processed to 
give a useful path.

 > Inventing a whole new syntax is something we should not do lightly 
especially
 > if there's other solutions. Most of the ordering ones can be done 
more easily by using an editor
 > and cut and paste without learning a new command set.
 > The differentiation between init and update is not really required in 
this case.

By now, having the user modify his .rosinstall by hand is what covers 
several usecases now anyway in the REP.
The problem with having an scm like syntax and a powerful ubiquitous 
command for init/add/merge/apply/update is to find a suitable name for 
that command. The word "install" can cover all of those, but "rosinstall 
install" looks silly. I also kept thinking of "dwim" (do what I mean). 
But that is also non-intuitive.

The differentiation between init, update, add, apply, merge, is not 
technically required, it is merely a usability issue.

 > I would suggest that we take the configuration methods you have layed out
 > here and use them in the rosws/rosworkspace discussion which Brian 
started.
 > And pare down the existing REP 110 draft to be just the SCM commands 
status, diff, and info.

The REP still has to mention the name of the command to use for 
init/add/update/apply/merge.
And I see no word in English that would serve the purpose (other than dwim).

The alternative is to use rosinstall without further command for that, 
but then the target directory may not be named after one of the other 
commands (or must be "escaped" e.g. as ./diff).

I also still argue for "regenerate" as a harmless way of updating one's 
setup.* files without touching anything else on the filesystem. However 
adding a confirmation questions before any change would make that 
somewhat obsolete.

So I still advocate the commands
status
diff
info
snapshot
check/wtf
[regenerate]

I'll wait for your suggestion, Tully, on how to deal with 
init/add/update/merge as an SCM-like command.



On 07/20/2011 08:12 PM, Tully Foote wrote:
> Hi,
>
> I think that the SCM syntax is good.  As proposed info and diff are 
> good extensions.  And as Dave suggested adding status would be good.
>
> snapshot is also probably a better name than --generate-versioned...  
> we can add that as an alias.
>
> The other commands start to get into configuration management and 
> although they share a lot of the names of SCM commands they actually 
> are noteably different. init, add, remove, apply, update, check.  
> Inventing a whole new syntax is something we should not do lightly 
> especially if there's other solutions.  Most of the ordering ones can 
> be done more easily by using an editor and cut and paste without 
> learning a new command set.  The differentiation between init and 
> update is not really required in this case.
>
> I would suggest that we take the configuration methods you have layed 
> out here and use them in the rosws/rosworkspace discussion which Brian 
> started.  And pare down the existing REP 110 draft to be just the SCM 
> commands status, diff, and info.
>
> Tully