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

Kevin Watts watts at willowgarage.com
Wed Jul 27 21:09:24 UTC 2011


As part of this rosinstall refactoring, are the open tickets on rosinstall
going to be addressed:
https://code.ros.org/trac/ros/query?component=rosinstall&status=new&status=assigned&status=reopened

Looks like there are about a dozen defect tickets on rosinstall.

Is it possible to patch the existing defects in rosinstall during the
Electric Beta? rosinstall has not been released in 4 months according to the
SVN logs. It would be nice to make rosinstall usable, even if we're working
on a replacement.

Kevin

On Mon, Jul 25, 2011 at 2:10 PM, Tully Foote <tfoote at willowgarage.com>wrote:

>
>
> 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
>
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20110727/2c0b7c6a/attachment-0003.html>


More information about the ros-users mailing list