[Distutils] RFC: Standard Declaration of tests in eggs

[Phillip J. Eby]

At 01:11 PM 1/5/2007 -0500, Jim Fulton wrote:
>Phillip J. Eby wrote:
>...
>>>Why can't an entry point invoke a test loader itself?
>>>This seems much simpler and more straightforward to me.
>>Because that requires you to write code for something that can adequately 
>>be expressed through an existing configuration mechanism.
>>*And* you have to write that code in every project.
>
>It's probably a couple of lines. Import a loader and call it.
>That doesn't seem like a big deal to me. Nice and explicit too.

And it's enormously repetitive if you have a lot of projects.


>Besides, I expect most projects will have a single test suite
>(function) that could just be named directly.

You expect wrongly.  :)  'nose' and 'py.test' are popular *precisely 
because* they do NOT require this.  Setuptools changed to emulate them by 
adding ScanningLoader, even though it originally did the "test suite 
function" thing you're proposing.

See, I originally wrote all my test suites the way you're proposing, but I 
changed because this is one of those "convention beats configuration" 
situations.  It's easier to just conform to a policy and have a tool that 
applies the policy.  Different projects may have different policies, so 
providing an option for the loader, allows them to follow it.  (And it made 
my life easier, too, as I began doing more small projects instead of a few 
large ones.)

And, if you want your approach to be widely adopted, it would be best to 
allow projects to follow their own policies without requiring them to add 
any code, even if it's a one-liner.

So, *technically*, there may be no reason to do this, but from a usability, 
friendliness, compatiblity, marketing, adoption, etc. format I don't think 
the standard will be successful without allowing this out.  People often 
have heavy psychological investment in existing tools, and it is hundreds 
of times easier to rationalize adding a line of configuration to setup() 
than it is to rationalize adding two or three lines of code.  One is merely 
a packaging change, the other is a programming change.