[RFC] depend on testtools for testing?

[Robert Collins]

On Thu, 2009-10-29 at 20:43 -0500, John Arbash Meinel wrote:
> 
> > 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.
> 
> Possibly, but would it install in C:\Python26\Lib\... or would it want
> to install in /usr/lib/python/...
> 
> Pluss "mingw" w/ autoconf + autopack + libtool + ??? is about 4 more
> packages than I currently have installed, and I have to track them all
> down manually. And last I remember, autoconf was especially sensitive
> to
> version matching with other tools.

years ago autoconf was very fragile and interconnected with a particular
automake version; that watershed is way behind us now.

> > 
> >> 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.
> 
> I have never personally used --parallel. My specific concern is that
> once we make it a hard dependency, then we have to very realistically
> concern ourselves with inter-version compatibility.  It might just be
> the answer that "the latest bzr runs with the latest testtools", but
> there certainly needs to be an answer. And once testtools becomes
> popular and people already have it installed via Lucid's package
> manager, do we start publishing the upgraded version in our ~bzr ppa
> because we started using newer features?

Possibly, the same as we might include paramiko if we needed a bugfixed
version.

> > 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.
> 
> As I understand it, you wanted to use testtools to make bzr's test
> runner compliant so that subunit could detect skips, rather than
> teaching subunit how bzr does it today.

No: changing the bzrlib internal interface to match upstream python will
do this in one step, testtools isn't involved or needed.

>  Without subunit understanding
> skips, we can't use --subunit because it will incorrectly handle skips
> as errors. (Either it never fails, or it always fails.)

[minor quibble: 'without subunit being given skips as skips']

> And we can't get a progress bar without using --subunit.  Thus by your
> proposal, we need testtools to get subunit to get a progress bar.

No, as above.

> > 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
> 
> Sure. I perfectly understood that point. I even stated it earlier (not
> wanting to do the work twice).
> 
> Note that specifically, once you've done the work on testtools, *bzr*
> will depend on *that* version of testtools, and presumably won't work
> with earlier versions. Or will have to have an amount of compatibility
> code, because older versions of testtools didn't handle skips in the
> same way that it will be done.

It will be a hard dep - thats the proposal ;).

> So there *is* a version dependency. And people wanting to hack on bzr
> will have to upgrade to a minimum version of testtools to get it.

Or users running selftest to validate their platform - they will need it
to.

> And that version of test tools will be a *lot* newer than our other
> dependencies. Namely python2.4, pyrex 0.9.6 or so, paramiko
> really-darn-old, and ?

We're already discussing moving to cython, and its a lot easier to drop
a small library into a system than it is to replace core functionality
like python.

-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/865c3b29/attachment.pgp