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

Thibault Kruse kruset at in.tum.de
Wed Jul 20 16:25:47 UTC 2011


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



More information about the ros-users mailing list