#general
- s
salmon-summer-38098
09/28/2015, 9:49 PMconfirmed, not using it - w
witty-crayon-22786
09/28/2015, 10:00 PM@limited-terabyte-34878: hey: ready when you are - l
limited-terabyte-34878
09/28/2015, 10:00 PMk thanks stu - l
limited-terabyte-34878
09/28/2015, 10:01 PMso the pytest timeout plugin seemed to work great for our purposes, but making @Test(timeout=) enforceable doesn’t seem feasible - l
limited-terabyte-34878
09/28/2015, 10:02 PMalso it leads to having to reimplement for every language - l
limited-terabyte-34878
09/28/2015, 10:02 PMItay pointed me to the pants_internal work he did for known to fail - l
limited-terabyte-34878
09/28/2015, 10:02 PMand the review board about custom arguments to targets - l
limited-terabyte-34878
09/28/2015, 10:02 PM - l
limited-terabyte-34878
09/28/2015, 10:03 PMso it seemed like it would be possible to implement this using a similar technique - l
limited-terabyte-34878
09/28/2015, 10:03 PMand also that if we can put custom arguments to targets into main pants that would help both known to fail and this timeout thing - w
witty-crayon-22786
09/28/2015, 10:04 PM@limited-terabyte-34878: before we get to that - w
witty-crayon-22786
09/28/2015, 10:04 PM@limited-terabyte-34878: i think the real argument that needs to be made is for a shared superclass of pytest and junit - w
witty-crayon-22786
09/28/2015, 10:06 PMbecause unless these timeouts are actually generic across test-running-tasks, there isn't much of an advantage over doing it in pytest and junit individually - w
witty-crayon-22786
09/28/2015, 10:06 PMwhich, i believe, was the argument that benjy and sirois were making - l
limited-terabyte-34878
09/28/2015, 10:06 PMyes, that’s true - l
limited-terabyte-34878
09/28/2015, 10:07 PMi hadn’t thought about creating that shared superclass last week, but clearly it’s a good approach - l
limited-terabyte-34878
09/28/2015, 10:07 PMat least it seems that way - l
limited-terabyte-34878
09/28/2015, 10:08 PMas my initial investigating into pants had me first looking for such a superclass and then seeing it wasn’t there - w
witty-crayon-22786
09/28/2015, 10:08 PMyea. how feasible it is is the next question. - w
witty-crayon-22786
09/28/2015, 10:09 PM@limited-terabyte-34878: @cuddly-architect-27013 is working on improving test coverage support for junit, so he'll be refactoring a bit in there as well - w
witty-crayon-22786
09/28/2015, 10:10 PM@limited-terabyte-34878: but extracting a small amount of shared logic into a parent class would probably make folks more amenable to doing this upstream - l
limited-terabyte-34878
09/28/2015, 10:10 PMi imagine one might want to start with maybe just an execute() stub - w
witty-crayon-22786
09/28/2015, 10:10 PMyea. and then some way to abort generically - w
witty-crayon-22786
09/28/2015, 10:12 PM@limited-terabyte-34878: the known_to_fail stuff is one way to go about this, but in any cases where it is possible to upstream this stuff, that should be our preference - l
limited-terabyte-34878
09/28/2015, 10:12 PMpants_internal has this TwitterTestTask class, which appears to wrap execute only - l
limited-terabyte-34878
09/28/2015, 10:12 PMby upstream you mean to put it into OS pants ? - w
witty-crayon-22786
09/28/2015, 10:12 PMyes. - w
witty-crayon-22786
09/28/2015, 10:13 PMnot TwitterTestTask per se. but the timeout implementation. - w
witty-crayon-22786
09/28/2015, 10:13 PM...or, not until we have a generic base trait probably. - w
witty-crayon-22786
09/28/2015, 10:15 PM@enough-analyst-54434, @happy-kitchen-89482 : would you guys agree that if we were able to extract a common test base class for the pytest and junit runners, it would make more sense to add native timeout support?