Bug 45838
| Summary: | Command.tool should not need to be a WebKitPatch subclass | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Eric Seidel (no email) <eric> |
| Component: | Tools / Tests | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW | ||
| Severity: | Normal | CC: | abarth, dpranke, mihaip |
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | PC | ||
| OS: | OS X 10.5 | ||
Eric Seidel (no email)
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.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Eric Seidel (no email)
(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.