On Tue, Sep 28, 2010 at 3:59 PM, Michael Foord <span dir="ltr"><<a href="mailto:fuzzyman@voidspace.org.uk">fuzzyman@voidspace.org.uk</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div bgcolor="#ffffff" text="#000000"><div class="im">
On 28/09/2010 14:17, Arve Knudsen wrote:
<blockquote type="cite">Hi Michael<br>
<br>
<div class="gmail_quote">On Mon, Sep 27, 2010 at 12:50 PM, Michael
Foord <span dir="ltr"><<a href="mailto:fuzzyman@voidspace.org.uk" target="_blank">fuzzyman@voidspace.org.uk</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
<div bgcolor="#ffffff" text="#000000">
<div> On 26/09/2010 19:43, Arve Knudsen wrote:
<blockquote type="cite">Hi
<div><br>
</div>
<div>As I've been tinkering with nose2 and unittest2,
and got to know the two better, the question has
emerged as to exactly which role nose2 is meant to
fulfill on top of unittest2.</div>
<div><br>
</div>
<div>With the original unittest, nose's raison de vivre
is pretty clear; seeing as unittest is rather an
archaic/inflexible framework, there is an obvious need
of a more modern, practical alternative. nose offers
such an improved alternative. unittest2 on the other
hand changes the game, as it is being designed with
today's needs in mind, and is plugin-based (like
nose). That unittest2 is a sound design is evidenced
by the fact that nose2 implements its functionality as
unittest2 plugins.</div>
<div><br>
</div>
</blockquote>
<br>
</div>
Hello Arve,<br>
<br>
Well, presuming to speak for Jason here (partly)... My
understanding, as author of the unittest2 plugins code, is
as follows.<br>
<br>
The purpose of the plugins machinery being developed for
unittest2 is to *allow* useful popular and frequently
requested functionality for unittest (such as that provided
by nose) to be provided in clean and simple ways. The
plugins branch itself is not *intended* to replace nose -
merely make it dramatically simpler to implement and
maintain. That at least is the goal.<br>
<br>
The situation is confused by the fact that in order to
ensure the plugins branch meets its goal I have implemented
various 'example' plugins that have some overlap with the
nose functionality. *However*, these plugins only cover a
relatively small subset of the nose functionality.<br>
<br>
The purpose of nose2 is to provide the functionality of nose
using unittest2 plugins. This includes goals like, wherever
possible, backwards compatibility with existing nose tests.
(But not existing nose plugins as the mechanisms are too
different.) </div>
</blockquote>
<div><br>
</div>
<div>OK, I guess that maintaining compatibility with legacy nose
tests is the distinguishing point here. I wasn't aware of that
particular design goal.</div>
<div><br>
</div>
<div>Personally I'd like to see the need for 3rdparty
unittest(2) wrappers to go away, for most uses. What I *think*
unittest2 should provide is a (more or less) state-of-the-art
test runner, with a sensible set of basic functionality, and
the ability to be extended with extra functionality. </div>
<div><br>
</div>
</div>
</blockquote>
<br></div>
Indeed, that is pretty much exactly the goal.</div></blockquote><div><br></div><div>Excellent!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div bgcolor="#ffffff" text="#000000">
<div class="im">
<blockquote type="cite">
<div class="gmail_quote">
<div>How about a general way of installing unittest2 plugins so
they are automatically detected by the unit2 runner? This is
how I'd like to be using unittest2 I think; the runner gives
me all the control I need (for example, stop on first failure)
and I can extend it with the domain-specific functionality
that I need (e.g., coverage analysis). Hudson is a good
analogue in this regard IMO; it's an excellent basic CI
system, but domain-specific functionality (e.g. Git
integration) is implemented through plugins. This design works
superbly in practice, I might add :)</div>
<div><br>
</div>
</div>
</blockquote>
<br></div>
When the extensions mechanism lands in distutils2 I will provide a
tool that that does this - detects and configures unittest2 plugins
for you.<br>
<br>
The alternative is that installing a unittest2 plugin (or any
package that also provides a unittest2 plugin) *automatically*
activates it. This would slow down startup and mean that the only
way of deactivating a buggy or unhelpful plugin is to uninstall the
package that provides it. I'm reluctant to do this, but could
provide an alternative runner (or command line switch perhaps) that
does this.</div></blockquote><div><br></div><div>Could you describe how detection/configuration of plugins would work? I'm curious. Could it be viable to configure unittest2 to automatically detect plugins, and also explicitly disable plugins (i.e., you want most plugins, and only need to disable a few)? It just struck me as a sensible middle ground.</div>
<div><br></div><div>Arve</div></div>