[RFC] depend on testtools for testing?

Francis J. Lacoste francis.lacoste at canonical.com
Thu Oct 29 21:39:28 GMT 2009

On October 29, 2009, John Arbash Meinel wrote:
> Francis J. Lacoste wrote:
> > On October 29, 2009, John Arbash Meinel wrote:
> >>> 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.
> >
> > buildout is a great tool to manage such dependencies automatically. Both
> > Launchpad and Lanscape are now using it. It's great for development, but
> > it won't solve the additional complexity in packaging. (bzr requires
> > testtools < 0.5, but the system .deb has 0.6 and you can't install both
> > in parallel.)
> We switched to using buildout to build our windows installers. So far,
> I'm less than impressed with it being a "great tool"... Perhaps we just
> haven't done enough yet, but it feels *way* too complex and fails
> regularly for my needs. (Not updating when it should, the build process
> taking a *very* long time just to scan the files that are already there,
> etc.) Some of it might be our build host, but I had a custom
> "build_release.py" that I was (so far) much happier with.

I'm sad to hear that. Maybe talk to Gary Poster (gary) about this, he might be 
able provide some helpful hints. 

Francis J. Lacoste
francis.lacoste at canonical.com
-------------- 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/287756f3/attachment.pgp 

More information about the bazaar mailing list