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

Wed Jul 20 20:21:54 UTC 2011

Hi guys,
would it be possible to include the feature to patch the code in rosinstall?
D.

On Wed, Jul 20, 2011 at 11:12 AM, Tully Foote <tfoote at willowgarage.com> 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
>
> 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
>
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
>

-- 
MSc. Dejan Pangercic
PhD Student/Researcher
Intelligent Autonomous Systems Group
Technische Universität München
Telephone: +49 (89) 289-26908
E-Mail: dejan.pangercic at cs.tum.edu
WWW: http://ias.cs.tum.edu/people/pangercic