<!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 text="#000000" bgcolor="#ffffff">
    On 28/09/2010 20:24, Arve Knudsen wrote:
    <blockquote
      cite="mid:AANLkTi=Rq7XSdQtSEyB=aZUw_DLNG23Z_G7ngRZjKqHe@mail.gmail.com"
      type="cite">[snip...]
      <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 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).&nbsp;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>
    </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>
    &nbsp;&nbsp;&nbsp; zero configuration for the case where you want installed plugins
    to be activated<br>
    Cons:<br>
    &nbsp;&nbsp;&nbsp; still needs manual configuration where you want to disable
    available plugins<br>
    &nbsp;&nbsp;&nbsp; needs to query all installed packages every time the runner
    starts<br>
    <br>
    Option 2:<br>
    <br>
    Pros:<br>
    &nbsp;&nbsp;&nbsp; no performance implications<br>
    &nbsp;&nbsp;&nbsp; more 'explicit': after installation plugins must be explicitly
    activated<br>
    Cons:<br>
    &nbsp;&nbsp;&nbsp; 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.<br>
    <br>
    All the best,<br>
    <br>
    Michael Foord<br>
    <br>
    <br>
    <blockquote
      cite="mid:AANLkTi=Rq7XSdQtSEyB=aZUw_DLNG23Z_G7ngRZjKqHe@mail.gmail.com"
      type="cite">
      <div class="gmail_quote">
        <div><br>
        </div>
        <div>Arve</div>
      </div>
    </blockquote>
    <br>
    <br>
    <pre class="moz-signature" cols="72">-- 
<a class="moz-txt-link-freetext" href="http://www.ironpythoninaction.com/">http://www.ironpythoninaction.com/</a>
<a class="moz-txt-link-freetext" href="http://www.voidspace.org.uk/blog">http://www.voidspace.org.uk/blog</a>

READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (&#8221;BOGUS AGREEMENTS&#8221;) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.

</pre>
  </body>
</html>