[RFC] depend on testtools for testing?

[Robert Collins]

On Thu, 2009-10-29 at 16:26 -0500, John Arbash Meinel wrote:

> > On the other hand, even for subunit which has a moderately sane
> > maintainer, getting a feature in did take noticeably longer than it
> > might have in bzr.
> > 
> > I agree with John's summary of some of the specific problems, and am
> > also ambivalent about taking such a change, defaulting to no.
> > 
> > Things that would move me away from that default:
> > 
> >  1- folks like Alexander who will be bitten about this saying "it's
> > really not a problem and a great idea" (or the opposite)
> > 
> >  2- the new dependency having actual compelling feature improvements
> > beyond what's in Bazaar

I think you have the sense inverted below - I *do* want to make bzr's
testing infrastructure compatible with upstream python.

> Well, I feel like one of Robert's pushes is that he doesn't want to make
> bzr's testing infrastructure compatible with the "standard way" of doing
> things, so that we can actually use --subunit on pqm. In that light, I
> can agree that it would be nicer to build on a tool that can be tweaked
> to conform to the standard, rather than having to do that work in 2 places.
> 
> I *did* like seeing a progress bar on PQM. I also liked getting a reject
> email that had all of the content and could be filtered more easily than
> just scrolling.

Sadly it was missing log file data - which is one of the things I want
to fix (and it is fixed in subunit, nearly fixed in testtools).

> I found subunit itself rather hard to install, because it is all based
> on an autoconf setup, because it adds support for more-than-just python.
> On Windows, that is just a lot of pain for me to try to work out. A
> 'setup.py' that *only* built/installed the python portion would have
> helped a lot there, and 'testtools' would be pure-python, so should
> avoid it. (I did an end-run and just run from source, but that isn't
> trivial either because of where the lib dir is versus the binaries,
> versus where 'python' is on my path, etc.)

I am willing to revisit having a setup.py for the python library. I
would have thought though, that just installing mingw w/autoconf
+automake+libtool would have let subunit build without trouble.

> I don't really know that getting a progress bar on PQM is worth the
> negatives of adding a dependency on a moving 'testtools' target...

Your primary concern seems to be version lockstepping? We *already* have
testtools as a dependency for 'selftest --parallel', so I don't see that
the version discussion is all that relevant to the 'hard or soft'
discussion - I don't know about you, but I exercise the testtools
integration all the time - and I think Vincent does too.

The hard dependency I'm proposing is not needed for a progress bar on
PQM, thats a totally different proposition - there we need to make sure
that all the extended test outcomes we use degrade more gracefully -
that is that if bzr can't represent the outcome in unittest.TestResult,
and our test run would have passed, that the degraded version also
passes.

At the heart of this is laziness - I don't want to write the same code
twice, when bzr already has a dependency on testtools, and testtools
will be getting the 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/20091030/526d79eb/attachment.pgp