The connection of rosinstall to ROS include also the mere existence of
managed non-scm entries to go into the ROS_PACKAGE_PATH, which would
make little sense in a multivcs tool, and the detection of a ROS_ROOT
directory.
And if there were a tool in 2012 called multivcs doing none of the
above, the ROS community would need a different tool doing all the
things above still, maybe based on multivcs. So I would like to avoid
renamig rosinstall now to mulstivcs assuming that what the ROS users
will have to use in the longer term future will change again. ROS users
need a tool with ROS connections, so I'd rather use a name with "ros" in
the REP.
I just need a name to put in the REP, it can be rosws, but that may be a
bit confusing for now while there is a different process developing
rosws with features that I put in and then removed again from the REP
(called "rosinstall shadow/overlay" and "rosinstall remove" at the
time). But maybe this confusion is bearable.
So shall I go for rosws for now, assuming Brians ideas will be
implementable as additional commands?
The roswtf API is called "very experimental", but I can still remove the
check command from the REP, though the checks should in my opinion still
run before each command to warn users.
On 07/25/2011 11:10 PM, Tully Foote wrote:
>
> Good point, also we've talked about making rosinstall be ROS
> independent, as it's only actual connection to ROS is the generation
> of the setup.(ba)sh scripts. But renaming to something like
> "multivcs" or "multiscm" would allow us to design the command line
> syntax w/o needing backwards compatability.
>
> And as rosws etc start being integrated we can let them leverage the
> new tool but retain ROS integration through that path.
>
> Also for the check/WTF sanity checks, I think it would be better to
> write a roswtf plugin which would check all those things. It will
> help keep a single debugging tool. And most of that is also ROS
> specific.
>
> Tully
(text/plain)