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

[Felix Kolbe]

Hello Thibault et al.,

I appreciate your working on rosinstall. It isn't that easy to
understand. And I really hate running it for an update because I get
absolutely no idea what had been changed and therefore will help or
disturb my development. If that's what your --diff is to be meant for,
that would be great! (Let me know if I missed the
view-detailed-changes-before-updating feature somewhere.)

Best Regards,
Felix


2011/7/20 Thibault Kruse <kruset at in.tum.de>:
> 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
>
_______________________________________________
ros-developers mailing list
ros-developers at code.ros.org
https://code.ros.org/mailman/listinfo/ros-developers