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

Wed Jul 20 18:12:55 UTC 2011

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

On Wed, Jul 20, 2011 at 9:25 AM, Thibault Kruse <kruset at in.tum.de> wrote:

> Hi,
>
> ok, in our latest git version, I removed shadow/overlay.
>
> I removed add + apply, and replaced them with "merge", which does what
> rosinstall does today.
> So if a user wants to add something that would get a same target path as
> something he already has, an attempt at merge is made (updating a
> version), else that fails. If a user wants to change versions according
> to some snapshot, that's also a merge.
> The other modifying commands are init, update and regenerate and remove.
>
> init is like merge, except it requires the target path to be empty, a
> ros root to be given, and in that it bootstraps ros
> update is like merge, except that it takes no further arguments (however
> changing the .rosinstall manually has the same effect as passing certain
> arguments).
> regenerate is different in that it performs no scm operations. it is
> like the "harmless" attempt to repair an environment.
>
> I'll adapt extend the unit tests for the current version, and then we
> may go ahead or reject the REP.
> if we reject the REP, I can still embed the functional changes I did to
> rosinstall as patches that do not change the syntax, such as
> rosinstall --diff
> rosinstall --info
>
> regards,
>   Thibault
>
>
>
> On 07/06/2011 06:05 PM, Ken Conley wrote:
> > So, some quick comments, hopefully more later:
> >
> > "rosinstall shadow"
> >   - we tend to use the nomenclature 'overlay' rather than shadow
> > (shadow is behind, overlay is on top)
> >   - I would recommend against implementing this right now.  Our
> > indexers currently only produce the latest 'trunk' of a resource,
> > which will frequently be the wrong resource.  The intent is to update
> > the indexer and roslocate command to respect version targets (e.g.
> > --distro diamondback), at which point a better version of this command
> > -- with different arguments -- could be implemented.
> >
> > "rosinstall apply"
> >   - As the REP itself indicates, I think this really confuses users to
> > introduce multiple, nearly identical commands.  It's the problem of
> > git, in my opinion, to elevate multiple, slightly different workflows
> > to top-level commands, rather than communicating a strong, good
> > workflow and demoting special cases to options/etc...  I would
> > personally leave apply out and make it an option on add.  The option
> > would more strongly communicate the different behavior, IMHO (e.g.
> > --replace)
> >
> > "rosinstall check --repair"
> >   - This seems like an unbounded feature, which is difficult for a tool
> > like rosinstall that needs to be stable.  I would break it out to a
> > separate tool.  Based on my own experience with roswtf, it's hard to
> > write and maintain tools that attempt to fix user's problems for them.
> >
> > "rosinstall change-ros"
> >   - I am uncertain of the driving U13 use case.  Now that ros is
> > separated into ros and ros_comm stacks, changing ros isn't effective
> > and can put you in a bad state.  Personally, more common for me is
> > changing distro from diamondback<->unstable.  That is much more
> > difficult to automate with rosinstall as it can be very install
> > specific (e.g. debian underlay).
> >
> > Basically, I think you've done good work with this, but I would shoot
> > for a smaller initial command set that is well focused, then
> > introducing too much too soon.
> >
> > cheers,
> > Ken
> >
> >
> >
> >
> > On Thu, Jun 30, 2011 at 1:33 PM, Thibault Kruse<kruset at in.tum.de>
>  wrote:
> >> Sorry, work is slow on REP 110.
> >>
> >> I created a second repo at
> >> http://code.in.tum.de/indefero/index.php//p/rosrelease2/
> >> containing ros_release with some small changes i required for
> >> rosinstall. You may pull from there (preferably into a folder where you
> >> svn checked-out ros_release), and in the rosinstall subfolder, pull from
> >> the
> >> http://code.in.tum.de/indefero/index.php//p/rosinstall2/
> >> repo my version. There is still a rosenv (rosinstall2) and a rosinstall
> >> script, where the rosinstall script is the original rosinstall plus all
> >> bugfixes for which I created tickets/patches and which I implemented in
> >> the rosenv script (for fair comparison).
> >>
> >> On my system, what works is to uninstall rosinstall, and then run
> >> sudo dpkg -r rosinstall
> >> make install
> >>
> >> in the rosinstall subfolder, simply confirming whatever the python
> >> install tool suggests.
> >>
> >> This copies the (patched) sources from ros_release/vcstools and then
> >> installs rosinstall. This is how it already was, I did not change this,
> >> I am largely ignorant and confused about python checkinstall. There
> >> might be some smarter way to achieve this, but i don't know it.
> >>
> >> I am slowly implementing sanity checks for rosinstall. I may skip
> >> implementing repair actions, as the code may be more of a burden than a
> >> blessing and just delay release of the REP.
> >>
> >> I still do not know whether the REP in the state it is in our repo
> >>
> http://code.in.tum.de/indefero/index.php//p/rosinstall2/source/tree/master/rosinstall-REP.txt
> >> is acceptable or needs rework.
> >>
> >> cheers,
> >>    Thibault
> >>
> >> _______________________________________________
> >> ros-developers mailing list
> >> ros-developers at code.ros.org
> >> https://code.ros.org/mailman/listinfo/ros-developers
> >>
> > _______________________________________________
> > ros-developers mailing list
> > ros-developers at code.ros.org
> > https://code.ros.org/mailman/listinfo/ros-developers
>
> _______________________________________________
> ros-developers mailing list
> ros-developers at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-developers
> _______________________________________________
> 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/20110720/54e3f7f4/attachment-0003.html>