0.11 kickoff

[jason pellerin]

With r506 in trunk, 0.11 is underway. Here are my priorities:

- the log capture plugin. Merged from ticket-148 branch in the
aforementioned r506. Remaining needs here are a comprehensive doctest
and real-world testing.

- collect-only plugin. I'm still looking for feedback on the question
of whether to integrate this with the test id plugin or have it stand
alone. Thoughts, anyone?

- parallelized test run plugin. I'm going to take a crack at this,
most likely using the processing package. If it looks like it will
delay the release beyond a month or so from now, I'll push it to a
later release.

- minor plugin api adjustments and deprecations in advance of the
expected large revisions to output handling in 0.12. These changes
*must* be backwards-compatible, I'm not going to stamp a new plugin
api version/entry point for 0.11.

Those are mine. What are yours? Keeping in mind that I'd like to see
0.11 out the door in 4-6 weeks, what can you commit to working on? Are
there any of my priorities above that you think don't make sense for
this release?

JP

[James Casbon]

HI Jason,

Looks all good to me. With regard to plugin api changes, I have a use
case for plugins handling formatting of tracebacks themselves. Please
see:
http://groups.google.com/group/nose-users/browse_frm/thread/db1c05dff6ca947a/30d12ef51aba3603#30d12ef51aba3603
There may be a better way!

Also, what's there any criteria for including plugin with the dist?
It is convenient not to have to manage packaging of a plugin all by
itself. However, presumably we don't want the dist to become
overloaded. Maybe a contrib dir or something could be good?

thanks,
James

[jason pellerin]

Hi James,

A formatTraceback hook sounds like a good addition, but adding a new
hook would require a new api version #, so it will have to wait for
0.12. Sorry.

The criteria for including a plugin with the dist are basically that
it must be stable and widely usable. I really like the idea of a
contrib package, but I'm not sure how to make it work. Would it be a
separate project and install? Who will volunteer to manage it? ;)

JP

[Kumar McMillan]

On Thu, Jun 5, 2008 at 9:47 PM, jason pellerin <jpel...@gmail.com> wrote:
>
> - parallelized test run plugin. I'm going to take a crack at this,
> most likely using the processing package. If it looks like it will
> delay the release beyond a month or so from now, I'll push it to a
> later release.

cool! time permitting, I can try to help.

> Those are mine. What are yours? Keeping in mind that I'd like to see
> 0.11 out the door in 4-6 weeks, what can you commit to working on? Are
> there any of my priorities above that you think don't make sense for
> this release?

It would be great to see the --xml plugin go into 0.11

I once blabbed that I can help finish this out from what Paul started
but I fear that might be too big of a commitment for me. Paul, are
you willing to make the final changes to push this into nose core?
Off the top of my head I *think* this is all that's needed:

- code, tests, and docs moved from google code to nose
- maybe a bit more docs on available formatters and how to write a new
formatter (preferably with doctests)
- fix the issue where warnings and other standard error output are not
captured in XML. I still think <stderr>all of it here</stderr> at the
beginning or end of the XML is adequate enough.
- some review of the current SAX / hooks implementation (I'd be happy
to do this once a working branch is in place that addresses the above
issues)

See http://code.google.com/p/python-nose/issues/detail?id=140