[RFC] depend on testtools for testing?

John Arbash Meinel john at arbash-meinel.com
Thu Oct 29 20:58:00 GMT 2009


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


...

> 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.

This is probably a fair source of errors. Specifically any library that
is evolving independently of bzrlib will end up with:
  a) We must always have the latest version of X
  b) We must have exactly version Y
  c) We bundle version Z in our source tree (bzrlib.util.testtools?)

I don't feel that testtools is sufficiently 'stable' today that we won't
run into the desire to go "fix" something, and then we start depending
on that fixed version.

If we had nested-trees then I would probably say "great", "bzr co
lp:bzr" also checks out "lp:testtools" and then you always have the
latest of both and we ensure that the version in bzr is compatible with
the version you got of testtools.

...

> 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.

If testtools was mostly stable, then it wouldn't be an incubator of
changes. (No changes in a stable object.) The idea that we want to get
updates is in conflict to the idea that we want to be compatible with a
(lot of?) version of the library.

> 
> 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

I'm concerned about the inability to enforce lock-step versions of bzr
and testtools if we are going to be updating testtools as we find bugs
and want new functionality, that we then depend on.

I like the idea of building on a good external library rather than only
having NIH with everything we do.

So I'm pretty much 50/50. Not strong enough to block, but concerned
about new problems that we'll encounter.

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkrqAdgACgkQJdeBCYSNAANk/ACeJUsgu2GwGtWiCjZZaDKouXK3
ybUAnRuc5leXzMK2lJWhxNGcsIxFXoak
=FSuf
-----END PGP SIGNATURE-----



More information about the bazaar mailing list