I think you can have most of what you want already.
You can then maintain several such rosinstall files and keep merging
them into your environment (by calling rosinstall . http://rnd.yujinrobot.com/ycs.rosinstall",
which can be in a script)
That's maybe not exactly what you want, but close.
It seems there are two uses for .rosinstall files - 1) as a snippet that is not useful standalone 2) as representative of a complete, standalone ros buildable source tree.
2) is convenient. I did think of using scripts to do as you say, but it's still awkward. You'd be using custom scripts + rosinstalls - two tools where one would be simpler and less to remember. In addition, if you wanted the flexibility of letting them target the script to a location of their choice, or running it with a nobuild option (or any of rosinstall's usual arguments), you then have to repeat all the rosinstall logic inside your scripts.
Else, maybe describe your workflow also.
Essentially we setup a .rosinstall for each robot, or environment. Being able to include other .rosinstalls would let us track moving changes in dependant .rosinstalls (e.g. the .rosinstall generated by ros' variants) and remove alot of copy/pasting commonly used stacks now that our rosinstall scripts are getting largish.
Daniel.
cheers,
Thibault
I just had a quick look in the rosinstall script for v0.5.22. With only a recursive call in class Config, method load_yaml():
Installs ok, added an overlay (i.e. added a repo and reran rosinstall) and it worked also. That gets it started - it'd need a little work to get rid of the exceptions thrown without a local-name element. The only other thing that might be desirable (but it works fine as is) is to expand the resultant ${ROS_WORKSPACE}/.rosinstall file which currnetly looks like this after the initial install + 2 overlays:
# THIS IS A FILE WHICH IS MODIFIED BY rosinstall
# IT IS UNLIKELY YOU WANT TO EDIT THIS FILE BY HAND
# IF YOU WANT TO CHANGE THE ROS ENVIRONMENT VARIABLES
# USE THE rosinstall TOOL INSTEAD.
# IF YOU CHANGE IT, USE rosinstall FOR THE CHANGES TO TAKE EFFECT
where ycs.rosinstall conveniently collects and maintains
its own working set. This would be fairly convenient to our
workflow, would it be a useful addition for others in
general?