[RFC] depend on testtools for testing?

[Francis J. Lacoste]

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