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

Thibault Kruse kruset at in.tum.de
Sun Jul 24 18:51:04 UTC 2011


Even though the thought may be heretic, a possibility to overcome the 
linguistic difficulty of expressiong

rosinstall install xyz

is to not call the script rosinstall, but something else. The reference 
implementation already uses the name "rosenv" for the script, though 
that was just because I wanted to keep it in sync with original 
rosinstall with minor patches.

Linguistically, I guess is makes sense that an SCM like syntax does not 
start with something that contains a verb.

As an example, take the roscommands, direkt args:

roscd
rosclean
roslaunch
rosconfig
roslocate
...

vs. those with an SCM like syntax:

rosbag
rosmsg
rosnode
rospack
rosservice
...

As you can see those with an SCM like syntax have as name ros + a noun, 
the others have ros + a verb.
So
rosinstall <command> would not fit.

so maybe we can find a suitable name for a noun of what rosinstall is about.
I like rosenv, but maybe others here prefer other solutions, like
rosdir, rosws (taken?), roslocal, ...
I don't know.

regards,
   Thibault


On 07/21/2011 08:15 PM, Thibault Kruse wrote:
> 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
> _______________________________________________
> 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