* Stefano Lattarini wrote on Sun, Mar 20, 2011 at 01:41:07PM CET: > On Sunday 20 March 2011, Ralf Wildenhues wrote: > > Or add a subunit parser and a quick tap2subunit perl module today > ["perl module"? what about portability?]
awk should be sufficient, for text-mode output at least. > > and have the best of both worlds? (This is meant as an honest question, > > even if it looks like a rhetoric one.) > > > I'd rather add a SubUnit parser only when *and if* the need arise; But look, going the other way round, there is little change you'll ever need to introduce an incompatible change later. > I have to admit that, by reading more carefully the README of subunit, > I'm intrigued by the fact that there seem to already be producers for > C, C++, Python, Perl and the shell... Still, I'm not confartable with > not being able to find documentation and examples that are clear enough > to allow me to define proper goals and progress estimation. This is fixable though, no? As far as I can see it, so far the arguments pro TAP are/were: - perl, rather than only python, support exists (but cf. your statement above), - simplicity, - well-definedness of the protocol. I don't see how subunit is not well-defined, looking at the EBNF in the README. I understand your desire to tackle simple first, and have something you can already overlook mostly. But summer is long, and even if it turns out too short: it's not necessary to finish exactly in time. I'm a bit intrigued by the fact that subunit appears to address a few deficiencies in TAP, and wonder whether we'd regret choosing TAP later. That said, I guess I'm fine with a project proposal along the lines of "try subunit support; and if that turns out too hard (e.g., for portability issues), then fall back to TAP", if you prefer a safety net. Cheers, Ralf
