On Wed, Sep 29, 2010 at 2:05 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 text="#000000" bgcolor="#ffffff">
On 28/09/2010 20:24, Arve Knudsen wrote:
<blockquote type="cite">[snip...]
<div class="im"><div class="gmail_quote">
<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>
<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>
</div></blockquote>
<br>
distutils2 allows installed packages to include metadata and
provides an API for querying that metadata. One of the proposed bits
of metadata is to be about extensions.<br>
<br>
unittest2 will be able to call an api that queries all packages
installed by distutils2 and gets back a list of all available
plugins.<br>
<br>
So there are basically two possible approaches:<br>
<br>
1) On startup the unittest2 test runner could call this api,
discover all available plugins and activate all of them except for
explicitly disabled ones.<br>
<br>
2) A config management tool could be used to show all available
plugins and activate / disable them (basically a configuration
management tool).<br>
<br>
Option 1:<br>
<br>
Pros: <br>
zero configuration for the case where you want installed plugins
to be activated<br>
Cons:<br>
still needs manual configuration where you want to disable
available plugins<br>
needs to query all installed packages every time the runner
starts<br>
<br>
Option 2:<br>
<br>
Pros:<br>
no performance implications<br>
more 'explicit': after installation plugins must be explicitly
activated<br>
Cons:<br>
installed plugins must be explicitly activated to be used<br>
<br>
Of course *both* are possible - with either two different test
runner scripts or a command line switch to choose between them.<br>
<br>
Whichever of these three options (1, 2 or both) is implemented,
alternative tools (like a GUI) could still be implemented to manage
the configuration.</div></blockquote><div><br></div><div>Sounds to me like we're on the same page, Michael!</div><div><br></div><div>Arve </div></div>