[RFC] depend on testtools for testing?

[Robert Collins]

lp:testtools is a project Jonathan Lange started to consolidate many
extensions to python unittest. There is considerable overlap with bzr's
test support infrastructure, and bzr currently depends on it for
selftest --subunit.

I'd like to delete from bzr the code that is present in both places for
a few reasons, primarily maintainability - I'm working with upstream
Python to get unittest's most blatant extensibility limitations fixed -
something that will [if successful] lead to bzr's tests working better
with IDE's and external tools (such as pqm's subunit support).

However, adding a new dependency always has some risk, and when
discussing this with Martin he was concerned that we'd make things
harder for folk to use or develop bzr.

A number of things could go wrong...

A matching version of testtools may be hard to obtain or install; it may
be home to new and exciting bugs, or we may not be able to get our bug
fixes into it.

testtools is, and will stay [unless $crazy happens] completely
pure-python. It isn't [yet] pypi installable, but it will be soon (there
is a name collision to resolve first). These two things mean that using
testtools should be very easy, and quite compatible with e.g.
virtualenv. Jonathan has made a team with commit access to testtools,
and an open, non-blocking commit policy, so being unable to get changes
into it is unlikely. Finally, I maintain the packaging of it in Debian
already, so rolling new packages is very straight forward.

Some things could go right however...

testtools may attract more users than bzr's own test-facilities, as
bzrlib is a pretty big dependency - and not one that we advertise;
testtools provides a small and clear code base to host infrastructure
code. Finally testtools goal is to be both an incubator for changes to
Python's unittest, and a host to backported versions of the upstream
changes - all of which means that using testtools allows access to the
'standard' way of doing things in newer Python versions without
upgrading.

Are there folk who object to adding a hard dependency on testtools for
'bzr selftest', given the above? Please speak up - I don't want to do
anything that makes developing or using bzr harder [but I also want to
reduce duplicated code :)]

-Rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20091029/b25b9310/attachment-0001.pgp