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

Tully Foote tfoote at willowgarage.com
Mon Jul 25 21:10:38 UTC 2011


On Sun, Jul 24, 2011 at 11:51 AM, Thibault Kruse <kruset at in.tum.de> wrote:

> 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.
>

Good point, also we've talked about making rosinstall be ROS independent, as
it's only actual connection to ROS is the generation of the setup.(ba)sh
scripts.  But renaming to something like "multivcs" or "multiscm" would
allow us to design the command line syntax w/o needing backwards
compatability.

And as rosws etc start being integrated we can let them leverage the new
tool but retain ROS integration through that path.

Also for the check/WTF sanity checks, I think it would be better to write a
roswtf plugin which would check all those things.  It will help keep a
single debugging tool.  And most of that is also ROS specific.

Tully


>
> 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
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20110725/f593f2b0/attachment-0003.html>


More information about the ros-users mailing list