<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
On 28/09/2010 14:17, Arve Knudsen wrote:
<blockquote
cite="mid:AANLkTik9=_mFe9qEtCn6iW1F7pfFXE5ihbxKW9wYWHvA@mail.gmail.com"
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 moz-do-not-send="true"
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>
Indeed, that is pretty much exactly the goal.<br>
<br>
<blockquote
cite="mid:AANLkTik9=_mFe9qEtCn6iW1F7pfFXE5ihbxKW9wYWHvA@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div>Thanks to you and Jason's information, I can now see that
nose2 only configures the unittest2 runner with nose2 plugins.
Thus, nose2 is really a unittest2 plugin suite with a specific
purpose (reimplement nose).</div>
<div><br>
</div>
</div>
</blockquote>
<br>
Well, yes... but nose functionality is not just to support legacy
tests. The nose2 plugins (already) provide genuinely useful
functionality as evidenced by the popularity of nose.<br>
<br>
It should (unless it grows additional functionality which could
happen) be possible to take any or all of the nose2 plugins and
manually configure them for unittest2 without using the nose2
script. The nose2 script is there as a convenience.<br>
<br>
<blockquote
cite="mid:AANLkTik9=_mFe9qEtCn6iW1F7pfFXE5ihbxKW9wYWHvA@mail.gmail.com"
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>
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.<br>
<br>
All the best,<br>
<br>
Michael Foord<br>
<br>
<blockquote
cite="mid:AANLkTik9=_mFe9qEtCn6iW1F7pfFXE5ihbxKW9wYWHvA@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div>Cheers,</div>
<div>Arve</div>
</div>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
<a class="moz-txt-link-freetext" href="http://www.voidspace.org.uk/">http://www.voidspace.org.uk/</a></pre>
</body>
</html>