Re: Numpy API change?

[Yaroslav Halchenko <debian@onerussian.com>]

On Thu, 22 Jul 2010, Barry Warsaw wrote:
> >But assuming that in longer run we agree on how we invoke unittesting for
> >Python modules we ship[...]

> I propose this be spelled: 'python setup.py test'.
> In my copious spare time <wink>, I'm working on code, documentation, and
> infrastructure to make this the preferred way of testing Python modules and
> applications.  You don't *have* to conform, but we'll put out big carrots for
> you if you do.
;-)

does setup.py test  just do unittesting? or + doctesting, regressions,
examples, ... ?

doesn't it re-build module first?

do you advocate also 'module.test()' may be for testing already
installed module whenever setup.py is no longer there?

Altogether setup.py test sounds like a viable solution for testing
within build tree (thus rebuilding the module/extensions); and I did see
some projects to provide similar targets (some times called
differently, e.g. nosetest, although 'test' sound better ).

But it doesn't provide means for testing of already built/installed
module.  Somewhat native approaches for this:
 * having module.test, so we could just 
    python* -c 'import module; module.test()'
   but that implies upstream willing to do so or our duty to hack it up
 * using 
    nosetests module
   but that is not guaranteed to work. Although nose's discovery is nice
   etc, project which is not 'nose aware'  might get all kinds of
   side-effects while invoking tests this way.
   on the other hand
    nosetests --with-doctests ...
   is very nice, but once again, some projects might not care about
   doctests

So, altogether, all those approaches require all upstreams to agree upon
the way things get tested... which I doubt would happen.

To account for heterogeneity among the projects why instead we just
not agree upon few debian/rules targets, e.g.

debian/rules test-available-*
 to run unittest battery (possibly with doctests and
 whatelse) with module.test() or
 nosetests or whatever upstream's native way.

 Rule might need to 'cd debian' or some other directory to assure
 that local source tree is not the one getting tested.

 -* is there for a python version to be used ease test-* below

debian/rules test-available
 to run against all supported python versions

and, dependent on successful build

debian/rules test-*
  which possibly just adjust the PYTHONPATHS and call corresponding 
  $(MAKE) test-available-$*
debian/rules test
  to test them all

Then for the validation of the packages which could just use
test-available and test targets within extracted source package

-- 
                                  .-.
=------------------------------   /v\  ----------------------------=
Keep in touch                    // \\     (yoh@|www.)onerussian.com
Yaroslav Halchenko              /(   )\               ICQ#: 60653192
                   Linux User    ^^-^^    [175555]