[Distutils] test suite support

[Thomas Heller]

From: "Moore, Paul" <Paul.Moore@atosorigin.com>
> From: Thomas Heller [mailto:thomas.heller@ion-tof.com]
> > You fear endless discussions resulting in no released code?
> 
> Exactly. Happens too often for my liking...
> 
> > Now that distutils doesn't have a named maintainer,
> > how are we supposed to proceed? Anyone writes a PEP, or
> > is this overkill?
> 
> I'd suggest that a PEP is overkill. I see PEPs as more related to Python
> language changes, rather than library issues (unless the library issue is
> far-reaching or fundamental).
> 
> I'd suggest a proposal to distutils-sig (basically, just a repost of your
> message with the suggested code in it), with a suggested discussion period
> of (say) 1 week. If no-one raises a showstopper objection in that time,
> check it in. Any discussion over the exact details of features should be
> noted but treated as requests for changes which can be submitted as patches
> *after* the release (unless they are small and non-controversial, when they
> can just be done).
> 
> Actually, I'd just check it in and wait for comments, but I like to live
> dangerously... :-)
> 
It seems the "official" way to do it would be to prepare the source
and then upload it as a patch to sourceforge. At least I would like
the people on python-dev to comment (most of them aren't subscribed
to distutils-sig).

One important point IMO: No additional code should be checked in
without proper documentation! Does anyone want to help here?

> > Anyway, lets try to clear this *fast*.
> 
> Yes.
> 
> Treating your suggested code as a proposal, I've a couple of comments. None
> to be treated as showstoppers - count me as +1 on checking this in
> regardless - but possibly worth consideration:
> 
> 1. What happens if there are no tests? Rather than silently doing nothing,
> I'd suggest printing "No tests defined", to act as a reminder that tests
> would be nice...
Hmm. Not sure...
> 
> 2. What is the code_coverage module? It's not standard, so I guess it should
> not be included in a standard distutils command. Although including code
> coverage reports in test results is nice, so using it if it is available,
> and skipping the coverage tests if not, might be good.
I should have removed them before posting the code, they were more or less
experimental (although they worked nice when I tried them).
Instead I would like to refactor the code a little, so that (in custom subclasses)
it would be easier to change/extend the tests.

Thomas