45838 2010-09-15 14:39:55 -0700 Command.tool should not need to be a WebKitPatch subclass 2010-11-04 15:10:19 -0700 1 1 1 Unclassified WebKit Tools / Tests 528+ (Nightly build) PC OS X 10.5 NEW P2 Normal --- 1 eric webkit-unassigned abarth dpranke mihaip oldest_to_newest 279736 0 eric 2010-09-15 14:39:55 -0700 Command.tool should not need to be a WebKitPatch subclass We need to break out a Tool subclass of WebKitPatch so that all the various commands which assume they have a self.tool.bugs, self.tool.scm, etc. can be run using something other than webkit-patch. This should mostly just be moving code. Adam started a patch to do this eons ago. The end goal is to make it simple to create a new Tool, multi-command style or not. For example, the following should be possible: class MyTool(MultiCommandTool, Tool): pass if __name__ == "__main__": MyTool().main() We'd probably need to teach it things about what directory to search for commands in, or how to give it a specific set of commands. We also eventually want to make it easy to create single-command tools. The MultiCommandTool argument-parsing and command calling logic should just be a mix-in. Tool is all the data storage. Command.tool needs to be a "Tool" but does not need to be a MultiCommandTool. 279843 1 eric 2010-09-15 17:19:48 -0700 (In reply to comment #0) > We need to break out a Tool subclass of WebKitPatch so that all the various commands which assume they have a self.tool.bugs, self.tool.scm, etc. can be run using something other than webkit-patch. I actually meant "Steps" not Commands. I don't expect other tools will re-use webkit-patch Command objects, but they could. Having a self.tool is pretty central to how the webkitpy command infrastructure works though.