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

Wed Jul 27 22:16:14 UTC 2011

 Open tickets are being serviced with the target of a new release before
Electric. 13 tickets have been closed in the last 2 weeks in preparation for
the next release. If you would like it to happen sooner patches are
welcome.

Tully

On Wed, Jul 27, 2011 at 2:09 PM, Kevin Watts <watts at willowgarage.com> wrote:

> 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
>>
>>
>
> _______________________________________________
> 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/20110727/63989a02/attachment-0002.html>