As part of this rosinstall refactoring, are the open tickets on rosinstall going to be addressed: https://code.ros.org/trac/ros/query?component=rosinstall&status=new&status=assigned&status=reopened Looks like there are about a dozen defect tickets on rosinstall. Is it possible to patch the existing defects in rosinstall during the Electric Beta? rosinstall has not been released in 4 months according to the SVN logs. It would be nice to make rosinstall usable, even if we're working on a replacement. Kevin On Mon, Jul 25, 2011 at 2:10 PM, Tully Foote wrote: > > > On Sun, Jul 24, 2011 at 11:51 AM, Thibault Kruse wrote: > >> Even though the thought may be heretic, a possibility to overcome the >> linguistic difficulty of expressiong >> >> rosinstall install xyz >> >> is to not call the script rosinstall, but something else. The reference >> implementation already uses the name "rosenv" for the script, though >> that was just because I wanted to keep it in sync with original >> rosinstall with minor patches. >> >> Linguistically, I guess is makes sense that an SCM like syntax does not >> start with something that contains a verb. >> >> As an example, take the roscommands, direkt args: >> >> roscd >> rosclean >> roslaunch >> rosconfig >> roslocate >> ... >> >> vs. those with an SCM like syntax: >> >> rosbag >> rosmsg >> rosnode >> rospack >> rosservice >> ... >> >> As you can see those with an SCM like syntax have as name ros + a noun, >> the others have ros + a verb. >> So >> rosinstall would not fit. >> >> so maybe we can find a suitable name for a noun of what rosinstall is >> about. >> I like rosenv, but maybe others here prefer other solutions, like >> rosdir, rosws (taken?), roslocal, ... >> I don't know. >> > > 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 > > >> >> regards, >> Thibault >> >> >> On 07/21/2011 08:15 PM, Thibault Kruse wrote: >> > Thanks Tully for the feedback, >> > >> > > 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. >> > >> > True for all but check. Though bzr check exists, but I'd also go with >> > rosinstall wtf >> > >> > I still think "check" may be useful, providing verbose information for >> > all that is strange but not dangerous, like >> > - stacks mentioned in .rosinstall but missing >> > - stacks in ROS_PACKAGE_PATH after ROS_ROOT >> > - duplicate URIs >> > - different .rosinstall and setup.sh >> > I think all future rosinstall should give warnings on such occasions, >> > and "check" would be the verbose information about the warnings. >> > >> > > And as Dave suggested adding status would be good. >> > >> > I will implement the status command. "info" in its current state already >> > shows a flag modified or not, but as a list of modified files, the >> > outputs of the scm status commands will have to be post-processed to >> > give a useful path. >> > >> > > 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. >> > >> > By now, having the user modify his .rosinstall by hand is what covers >> > several usecases now anyway in the REP. >> > The problem with having an scm like syntax and a powerful ubiquitous >> > command for init/add/merge/apply/update is to find a suitable name for >> > that command. The word "install" can cover all of those, but "rosinstall >> > install" looks silly. I also kept thinking of "dwim" (do what I mean). >> > But that is also non-intuitive. >> > >> > The differentiation between init, update, add, apply, merge, is not >> > technically required, it is merely a usability issue. >> > >> > > 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. >> > >> > The REP still has to mention the name of the command to use for >> > init/add/update/apply/merge. >> > And I see no word in English that would serve the purpose (other than >> dwim). >> > >> > The alternative is to use rosinstall without further command for that, >> > but then the target directory may not be named after one of the other >> > commands (or must be "escaped" e.g. as ./diff). >> > >> > I also still argue for "regenerate" as a harmless way of updating one's >> > setup.* files without touching anything else on the filesystem. However >> > adding a confirmation questions before any change would make that >> > somewhat obsolete. >> > >> > So I still advocate the commands >> > status >> > diff >> > info >> > snapshot >> > check/wtf >> > [regenerate] >> > >> > I'll wait for your suggestion, Tully, on how to deal with >> > init/add/update/merge as an SCM-like command. >> > >> > >> > >> > On 07/20/2011 08:12 PM, Tully Foote 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 >> > _______________________________________________ >> > ros-users mailing list >> > ros-users@code.ros.org >> > https://code.ros.org/mailman/listinfo/ros-users >> >> _______________________________________________ >> ros-users mailing list >> ros-users@code.ros.org >> https://code.ros.org/mailman/listinfo/ros-users >> > > > > -- > Tully Foote > Systems Engineer > Willow Garage, Inc. > tfoote@willowgarage.com > (650) 475-2827 > > _______________________________________________ > ros-users mailing list > ros-users@code.ros.org > https://code.ros.org/mailman/listinfo/ros-users > >