At 03:30 PM 8/12/2005 -0500, Ian Bicking wrote:
However, I believe each command to setup.py is simply an "entry_point". I can't find documentation for that at the moment. But it's something like this in the setup.py file:
entry_points={ 'distutils.commands': [ 'test=test_module:test_command', ], }
Yes, that's exactly it.
And then that test_command object (a class) has a specific interface (based on the distutils.Command class). So potentially a py.test-using project could do:
entry_points={ 'distutils.commands': [ 'test=mypkg.commands:test']}
# in mypkg.commands: from py.test.disutils import test
I think that would override "setup.py test" for just that package.
Actually, it wouldn't, because the first 'test' command defined on sys.path will get used. This doesn't mean that we can't have define test entry points, though, that the setuptools 'test' command would then use to run other testing frameworks. For example, the builtin 'test' command could look up a 'test' command in the just-built package and run that. The problem is that the master test command will have to define what options it takes, because distutils doesn't delegate option parsing to the commands. :( But setuptools does offer another solution. In py.test's you could create a 'py.test' setup command, and projects that want to use it can do: setup( ... setup_requires=['py-test>=someversion'], project_args_for_py_test_here="something", ) They can also define a project alias in setup.cfg: [aliases] test = py.test This will make "setup.py test" run the "py.test" command instead. But to me, the simple and obvious thing to do is to make test suites. If py.test exports a zero-argument function that finds tests in the current directory and returns a suite, then a py.test-using package need only set 'test_suite="py.test.get_suite"' in order to use it, with no need to define an alias, nor would py.test need to define another distutils command. And, for basic "does this work?" testing, users get a uniform interface for the 'test' command.