Phillip J. Eby wrote:
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. :)
I can only speak based on my own experience. Projects like Zope
and ZODB certainly want some sort of tool to find and assemble tests.
Eggs are allowing and encouraging us to move away from such large projects.
As we break up Zope into individual packages, I'm finding that the individual
packages have single test suites.
'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.
They'll be adding code one way or another. Either they add it to
their test modules, or they add it to setup.py. The advantage of
the former is that it provides more flexibility without requiring
any more work. It is also more explicit.
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.
We disagree.
I don't have any problem with having tools that can be used to find
and assemble tests into a test suite. I find the unittest loader
framework to be baroque. I'd rather let people use whatever framework
they want to do this and to control this from Python.
I withdraw the proposal. I wouldn't object to the proposal you want,
if you want to write it. I don't have the time or interest to write
it myself.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
